[swift-users] Bool to Int

[Kenny Leung]

Sorry, I really don’t understand what’s going on with this code.

So in that respect, I guess it is magic.

-Kenny


> On Nov 22, 2016, at 11:21 AM, Adrian Zubarev <adrian.zubarev at devandartist.com> wrote:
> 
> Want to see some real magic?
> 
> struct A : _ExpressibleByBuiltinIntegerLiteral {
>      
>     init(_builtinIntegerLiteral value: _MaxBuiltinIntegerType) {}
> }
> 
> struct B : ExpressibleByIntegerLiteral {
>      
>     init(integerLiteral value: A) {
>          
>         print(type(of: value))
>     }
> }
> 
> let b: B = 42 // prints "A"
> 
> My integer literel type is now A and not any of the (U)Int(8,16,32,64) family.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 22. November 2016 um 19:36:26, Kenny Leung via swift-users (swift-users at swift.org) schrieb:
> 
>> Hi Marc.
>> 
>> My old mechanical engineering prof used to say, “C is easy if you know assembler”. 
>> 
>> The fact that such a simple construct does not work and requires such a long explanation - which may still not be understood by a newbie - is a problem that should be addressed.
>> 
>> Even this explanation requires that you “see inside” the compiler to know what it’s “thinking”. And the fact that NSNumber comes into this makes it more interesting. What would be the behaviour (or at least the error message) on Linux, where there is no NSNumber? (or is there? I’m even more confused - have to try it out for myself).
>> 
>> We are also getting complacent when “A literal doesn’t have a type on its own. Instead, a literal is parsed as having infinite precision and Swift’s type inference attempts to infer a type for the literal.” gets condensed down to “literals in Swift are untyped” I don’t think this helps the explanation when there really is a distinction between different types of literals (otherwise there wouldn’t be things like ExpressibleBy*Boolean*Literal).
>> 
>> I think part of it is the way the documentation itself is worded. Another part here is the weird side effect Objective-C compatibility brings into the picture.
>> 
>> I think I’m turning this into a swift-evolution topic:
>> * should Int(Bool) be supported in the standard library?
>> ** if so, then Int(t) should work here
>> ** if not, then Int(true) should also error to avoid confusion
>> 
>> -Kenny
>> 
>> 
>> > On Nov 21, 2016, at 3:09 PM, Marco S Hyman via swift-users <swift-users at swift.org> wrote:
>> > 
>> >> Except it does, because if I write
>> >> 
>> >> let a = 2
>> > 
>> >> a is of type Int (at least, according to Xcode's code completion).
>> > 
>> > and if you write
>> > 
>> > let b = 2 + 0.5
>> > 
>> > 2 is treated as a double. The type of the literal “2” varies with context. Do you also find that inconsistent and confusing? 
>> > 
>> >> But this gives inconsistent results:
>> >> 
>> >> let t = true
>> >> 
>> >> let a = Int(true)
>> >> let b = Int(t)	// Error
>> >> 
>> >> I find this to be very inconsistent and confusing.
>> > 
>> > t is a Bool and there is no automatic conversion from Bool to Int.
>> > 
>> > true is not a Bool. It may be treated as a Bool depending upon context. In the line `let t = true` it is treated as a Bool. In `let a = Int(true)` it is treated as an NSNumber (assuming you import foundation).
>> > 
>> > Marc
>> > _______________________________________________
>> > swift-users mailing list
>> > swift-users at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-users
>> 
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users