This behaves as intended.

 CharOrSectionMarkerScalar.Char(Unicode.Scalar(9992)) 

For this example, the type of the literal ends up being UInt8 (because there is only one initializer of Unicode.Scalar which takes an integral value). Hence you get the compilation error because of the overflow.

CharOrSectionMarkerScalar.Char(Unicode.Scalar(9992)!)

For this example, a failable initializer is used due to the outer !. Unicode.Scalar has three failable initializers which take integral values. An integer literal defaults to Int in the absence of additional type information, so that initializer is used. Since 9992 fits in the range of Int, there is no compilation error.

Comment by bohong sun (JIRA)

theindigamer (JIRA User)

1、

Since 9992 is a legal parameter, it should return a legal value,not Some<Unicode.Scalar>

2、

Moreover, the following error message is more appropriate. It can help developers avoid confusion.

> Since 9992 is a legal parameter, it should return a legal value,not Some<Unicode.Scalar>

I don't understand what you mean by "legal parameter". If you look at the initializers for Unicode.Scalar (https://developer.apple.com/documentation/swift/unicode/scalar), those are:

1. init(UInt8)
2. init(Unicode.Scalar)
3. init?(UInt32)
4. init?(UInt16)
5. init?(Int)
6. init(unicodeScalarLiteral: Unicode.Scalar)
7. init?(String) 

As I said above, in the case with a force-unwrap, initializer 5 is selected (which has a ? indicating that it returns an Optional). In the case without the force-unwrap, initializer 1 is selected, which gives the overflow error.

> Moreover, the following error message is more appropriate.

The reason you are seeing different error messages is because s0 has type Unicode.Scalar?, whereas when you write CharOrSectionMarkerScalar.Char(Unicode.Scalar(9992)) directly, the inner temporary has type Unicode.Scalar (no optional) because the associated value for the CharOrSectionMarkerScalar.Char case is expected to have type Unicode.Scalar.

Could you clarify what the central issue is?

1. Is the issue that the overflow diagnostic doesn't make sense/is difficult to understand?

2. Are you suggesting that the code example with CharOrSectionMarkerScalar.Char(Unicode.Scalar(9992)) should compile?

3. Something else?

Comment by bohong sun (JIRA)

1、The overflow diagnostic is difficult to understand. We could make it more understandable.

2、9992 is a valid Unicode code point

///     let airplane = Unicode.Scalar(9992)

///     print(airplane)

///     // Prints "✈︎"

And https://developer.apple.com/documentation/swift/unicode/scalar/2905753-init lists the legal range

0...0xD7FF or 0xE000...0x10FFFF.

CharOrSectionMarkerScalar.Char(Unicode.Scalar(9992)) should be compile and Unicode.Scalar(9992) should't be a Unicode.Scalar?, {{}} it should be Unicode.Scalar？

> Integer literal '9992' overflows when stored into 'UInt8'

Point taken, I've filed SR-13429 to improve that.

> 9992 is a valid Unicode code point

Sure, that's why the initializer succeeds and returns .some("✈︎") instead of nil.