# 1 + 'a' = 'b'
**URL:** https://discourse.julialang.org/t/1-a-b/77947
**Category:** General Usage
**Created:** [March 16, 2022, 5:52am UTC](https://discourse.julialang.org/t/1-a-b/77947 "2022-03-16T05:52:33Z")
**Posts on this page:** 20
**Page:** 3
### Author:  [@cjdoris](https://discourse.julialang.org/u/cjdoris)
#### Post date: [March 16, 2022, 3:52pm UTC](https://discourse.julialang.org/t/1-a-b/77947/42 "2022-03-16T15:52:15Z")
> [@Sukera](#):
>
> My point is that this has nothing to do with the _encoding_ , as that argument breaks down as soon as you have multibyte characters (same goes for the pointer argument!).
No it doesn’t, somewhere further down the sequence is `..., 'α', 'β', ...` as defined by Unicode.
---
### Author:  [@josuagrw](https://discourse.julialang.org/u/josuagrw)
#### Post date: [March 16, 2022, 3:53pm UTC](https://discourse.julialang.org/t/1-a-b/77947/43 "2022-03-16T15:53:34Z")
> [@oheil](#):
>
> It is implicit.
I think this goes to the core of my line of argument: `'a' + 1=='b'` is implicit _only_ if we consider `'a'` and `'b'` as representations of the letters _a_ and _b_.
It is _explicit_ if we consider `'a'` and `'b'` as representations of Unicode code points.
---
### Author:  [@cjdoris](https://discourse.julialang.org/u/cjdoris)
#### Post date: [March 16, 2022, 3:55pm UTC](https://discourse.julialang.org/t/1-a-b/77947/44 "2022-03-16T15:55:31Z")
> [@Sukera](#):
>
> Viewed from that perspective, one could also argue that `iterate(Char, 1234)` should give the 1234th character in UTF-8, though I think hardly anyone would think that as a sensible API either.
Types aren’t iterable. You can’t do `iterate(Int, 1234)`.
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [March 16, 2022, 3:55pm UTC](https://discourse.julialang.org/t/1-a-b/77947/45 "2022-03-16T15:55:58Z")
> [@oheil](#):
>
> It is implicit
Whatever it is, it’s not a cast or a promotion.
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [March 16, 2022, 3:56pm UTC](https://discourse.julialang.org/t/1-a-b/77947/46 "2022-03-16T15:56:37Z")
> [@cjdoris](#):
>
> No it doesn’t, somewhere further down the sequence is `..., 'α', 'β', ...` as defined by Unicode.
Yes, it does. You’re talking about the order, which is not the _encoding_. The OP was talking about interpreting `'a' + 1` as adding 1 to the encoding (in ASCII) which just happens to match up for some values, but not all - namely multibyte characters/codepoints, which don’t have this property anymore at e.g. multibyte boundaries, where the next character gets an additional byte.
---
### Author:  [@josuagrw](https://discourse.julialang.org/u/josuagrw)
#### Post date: [March 16, 2022, 4:01pm UTC](https://discourse.julialang.org/t/1-a-b/77947/47 "2022-03-16T16:01:22Z")
> [@Sukera](#):
>
> don’t have this property anymore at e.g. multibyte boundaries
I think this is unnecessarily pedantic. But okay, from now on I will say “code points”. Let’s see when the next person finds a flaw with that word choice…
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [March 16, 2022, 4:01pm UTC](https://discourse.julialang.org/t/1-a-b/77947/48 "2022-03-16T16:01:56Z")
On top of all of this, there are also explicit _noncharacters_ (see [wikipedia](https://en.m.wikipedia.org/wiki/Unicode)):
> A small set of code points are guaranteed never to be used for encoding characters, although applications may make use of these code points internally if they wish. There are sixty-six of these noncharacters: U+FDD0–U+FDEF and any code point ending in the value FFFE or FFFF (i.e., U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, … U+10FFFE, U+10FFFF).
So not even the interpretation of “add 1 to the codepoint” holds.
---
### Author:  [@oheil](https://discourse.julialang.org/u/oheil)
#### Post date: [March 16, 2022, 4:02pm UTC](https://discourse.julialang.org/t/1-a-b/77947/49 "2022-03-16T16:02:30Z")
There is nothing like _we consider_
We can agree here or in the docs for anything and make it explicit with that.
Still this doesn’t solve the OPs problem, that somebody considered something else and stumbled about the facts.
The important problem here is, that in some code i see:
`'a' + 1`
and it’s not clear what does it mean from itself. I have to consult the docs and, good luck, it is explicitly mentioned there. In this case. Well done, Julia docs people!
My opinion, in this special case, is, that we should have a function
`nextchar('a')`
for this, like we have `nextfloat`, because `'a' + 1` is surprising and e.g. `'1' + 1` is different in different languages.
But anyhow, I don’t have any strong feelings about this. But mathematical stringency will not solve this and doesn’t help.
The pragmatic path of Stefan to open a PR for 2.0 is it.
---
### Author:  [@cjdoris](https://discourse.julialang.org/u/cjdoris)
#### Post date: [March 16, 2022, 4:03pm UTC](https://discourse.julialang.org/t/1-a-b/77947/50 "2022-03-16T16:03:15Z")
> [@oheil](#):
>
> > [@cjdoris](#):
> >
> > from a mathematical point of view.
>
> which doesn’t really help for the original question.
> But it generates more questions, like: should we than treat Float64 as sequence in this mathematical sense and distinguish between `1.0 + 1` and `1.0 + 1.0` . I don’t think so.
Mathematical formalism is how good programming languages are made. In Julia:
- `+(::T,::T)` is used for (usually commutative) group operations (e.g. `1+2` or `[1,1]+[2,2]`)
- `*(::T,::T)` is used for monoid operations (in particular the multiplicative operation when `T` forms a ring) (e.g. `1*2`, `[1]*[2]` or `"foo"*"bar"`)
- `+(::T,::S)` is used for group actions (which generalise the notion of group operation) (e.g. `'a'+1`, `Ptr{Cvoid}(3)+2` or `1.2+3`)
- `-` and `/` are the corresponding inverses.
Since group actions generalise group operations, you can view `1+1.0` and `1.0+1.0` both as either a group operation or an action and you get the same conclusion.
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [March 16, 2022, 4:03pm UTC](https://discourse.julialang.org/t/1-a-b/77947/51 "2022-03-16T16:03:49Z")
Sukera, no. Even “non characters” are `Char`s:
```julia
julia> '\UFDD0'
'\ufdd0': Unicode U+FDD0 (category Cn: Other, not assigned)
```
Julia’s Char is not UTF8. It’s a unicode code point. That’s why it prints out the unicode code point.
---
### Author:  [@oheil](https://discourse.julialang.org/u/oheil)
#### Post date: [March 16, 2022, 4:04pm UTC](https://discourse.julialang.org/t/1-a-b/77947/52 "2022-03-16T16:04:00Z")
> [@DNF](#):
>
> Whatever it is, it’s not a cast or a promotion.
This is not important here.
That it is implicit is the reason for the arguing.
---
### Author:  [@cjdoris](https://discourse.julialang.org/u/cjdoris)
#### Post date: [March 16, 2022, 4:07pm UTC](https://discourse.julialang.org/t/1-a-b/77947/54 "2022-03-16T16:07:58Z")
> [@Sukera](#):
>
> The OP was talking about interpreting `'a' + 1` as adding 1 to the encoding (in ASCII)
The OP never mentioned encodings or ASCII.
---
### Author:  [@oheil](https://discourse.julialang.org/u/oheil)
#### Post date: [March 16, 2022, 4:13pm UTC](https://discourse.julialang.org/t/1-a-b/77947/55 "2022-03-16T16:13:05Z")
> [@cjdoris](#):
>
> Since group actions generalise group operations, you can view `1+1.0` and `1.0+1.0` both as either a group operation or an action and you get the same conclusion.
I don’t know, probably don’t understand it the right way, but than my conclusion is:
`1.0 + 1.0 = 2.0` the group operation
and
`1.0 + 1 = nextfloat(1.0)` the group action
for `Float64`.
are not the same.
Like in
`'a' + 1 = nextchar('a') = 'b'`
or
`next_codepoint` instead of `nextchar`.
---
### Author:  [@cjdoris](https://discourse.julialang.org/u/cjdoris)
#### Post date: [March 16, 2022, 4:20pm UTC](https://discourse.julialang.org/t/1-a-b/77947/56 "2022-03-16T16:20:13Z")
I assume everyone here is ok with `Date(2022, 3, 16) + Day(1)` returning `Date(2022, 3, 17)`?
This is an addition where the operands are of different types and there is no promotion.
The reason it makes sense is because there is a sensible notion of subtraction between different dates, and we can measure it in days - the difference between tomorrow and today is one day.
There is no particular need for the difference between two things to be of the same type as the thing itself. Sometimes they are the same, such as the difference between integers is also an integer.
Oftentimes they are different. The difference between dates is measured in days. The difference between cities is measured in miles. In Julia, the difference between characters is an integer.
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [March 16, 2022, 4:23pm UTC](https://discourse.julialang.org/t/1-a-b/77947/57 "2022-03-16T16:23:30Z")
Implicit what? I cannot be just ‘implicit’.
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [March 16, 2022, 4:26pm UTC](https://discourse.julialang.org/t/1-a-b/77947/58 "2022-03-16T16:26:37Z")
> [@mbauman](#):
>
> Julia’s Char is not UTF8. It’s a unicode code point. That’s why it prints out the unicode code point.
Yes, I’m aware! 🙂 However, the section I’ve quoted is not from the UTF-8 spec - Unicode itself says these are noncharacters. The very next part of the text even acknowledges that this is often ignored:
> Like surrogates, the rule that these cannot be used is often ignored, although the operation of the byte order mark assumes that U+FFFE will never be the first code point in a text.
As such, while julia can represent them, you can’t (shouldn’t?) expect to be able to do anything with them and (depending on how closely you want to follow the spec) can’t necessarily assume that it exists at all.
* * *
To be quite clear, I agree with all of you that the `+ 1` API is horrible and what is “meant” is “give me the next codepoint I can reasonably do something with”, even though the result may not be possible to actually encode in a valid unicode string (however encoded).
As mentioned above though, we’re stuck with it for now.
---
### Author:  [@josuagrw](https://discourse.julialang.org/u/josuagrw)
#### Post date: [March 16, 2022, 4:28pm UTC](https://discourse.julialang.org/t/1-a-b/77947/59 "2022-03-16T16:28:21Z")
> [@Sukera](#):
>
> I agree with all of you that the `+ 1` API is horrible
I don’t think it is horrible. When we think of `Char`s as code points, the operation makes perfect sense.
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [March 16, 2022, 4:32pm UTC](https://discourse.julialang.org/t/1-a-b/77947/60 "2022-03-16T16:32:25Z")
Julia’s Char can explicitly — as a design goal — hold arbitrary data including potentially invalid unicode points.
```julia
julia> Char(0x11FFFF)
'\U11ffff': Unicode U+11FFFF (category In: Invalid, too high)
```
Doing anything different removes your ability to programmatically fix encoding issues in your data.
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [March 16, 2022, 4:53pm UTC](https://discourse.julialang.org/t/1-a-b/77947/61 "2022-03-16T16:53:49Z")
Yeah, I don’t know if it’s exactly _horrible_. One should be able to express both something like `nextchar`, and measuring distance between characters. `+(::Char, ::Int)` and `-(::Char, ::Char)` are a symmetric pair that is both convenient and respect algebraic manipulation.
---
### Author:  [@oheil](https://discourse.julialang.org/u/oheil)
#### Post date: [March 16, 2022, 5:07pm UTC](https://discourse.julialang.org/t/1-a-b/77947/62 "2022-03-16T17:07:12Z")
implicit in contrast to explicit.
In
`'a' + 1`
there happens some _implicit_ magic, which is hidden to the programmer who types or read this code snippet. He can not be sure, what the result is, without trying it or reading the docs. In Julia `'1' + 1` is `'2'`, but not in other languages.
This is meant by _implicit_.
The explicit version of the same result is:
`Char(Int('a')+1)`
where everything is explicitly written out and you can guess the outcome easily, still you can’t be sure.
I say _guess_ and _result_ by purpose, because it’s not the explicit code version for `'a' + 1`. It just produces the same result in the case of ‘a’ and it may fail for other characters.
The equivalent explicit code version would be:
```julia
Char(Int32('a') + Int32(1))
```
So, it’s not important that it is a cast, a promotion or a special function for the problem. The source of problem here is that some hidden magic (implicitly) happens.
This is often not a problem at all, as for example in
```julia
Date(2022, 3, 16) + Day(1)
```
as, from the types, it’s clear enough, that probably the next day as a `Date` is the result.
For a Julia beginner this
```julia
"1" * "2"
```
can be a problem and he may has to check the docs.
Operator `*` is concatenation for `String` in Julia, one has to know it.
Now
```julia
'1' + 1
```
is what?
It’s up the individual on how to comprehend it. For some it’s clear, for some others not.
Hence
```julia
nextchar('1')
```
would be my suggestion and remove `'1' + 1` and my argument is taste in this very special case of `Char`.
[Previous page](https://discourse.julialang.org/t/1-a-b/77947.md?page=2)
[Next page](https://discourse.julialang.org/t/1-a-b/77947.md?page=4)