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
> wrote:
>
> Want to see some real magic?
>
> struct A : _ExpressibleByBuiltinIntegerLiteral {
>
> init(_builtinIntegerLi
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 = 4
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
Where is your problem here? It’s simple and easy ;)
extension Integer {
init(_ boolean: Bool) {
self = boolean ? 1 : 0
}
}
Int(10 > 4)
UInt32(1 <= 2)
--
Adrian Zubarev
Sent with Airmail
Am 22. November 2016 um 00:54:47, Rick Mann via swift-users
(swift-users@
> On Nov 21, 2016, at 15:09 , Marco S Hyman 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” va
> 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?
> On Nov 21, 2016, at 13:14 , Nevin Brackett-Rozinsky
> wrote:
>
> I don’t see what there is to be confused about.
>
> A “literal” is literally a bunch of characters in source code. The compiler
> interprets those characters as representing whatever type is appropriate to
> the context.
>
>
I don’t see what there is to be confused about.
A “literal” is literally a bunch of characters in source code. The compiler
interprets those characters as representing whatever type is appropriate to
the context.
For the case at hand, a boolean literal can be interpreted as any type
which conform
> On Nov 21, 2016, at 09:46 , Kenny Leung via swift-users
> wrote:
>
> This is so confusing. "Literals are untyped", but there’s a “BooleanLiteral”,
> which is obviously of type Boolean.
Agreed.
--
Rick Mann
rm...@latencyzero.com
___
swift-users
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.
Source
--
Adrian Zubarev
Sent with Airmail
Am 21. November 2016 um 18:46:32, Kenny Leung via swift-users
(swift-users@swif
This is so confusing. "Literals are untyped", but there’s a “BooleanLiteral”,
which is obviously of type Boolean.
-Kenny
> On Nov 21, 2016, at 2:49 AM, Adrian Zubarev via swift-users
> wrote:
>
> In general this is a correct behaviour, because literals in Swift are
> untyped. Int does not h
In general this is a correct behaviour, because literals in Swift are untyped.
Int does not have any initializer for a Bool so the compiler tries to find a
type that might conforms to ExpressibleByBooleanLiteral for all possible
initializer of Int (Int.init(_: TYPE)). This resolution decides to
I'll try profiling it (or looking at the generated assembly).
Thanks!
> On Nov 20, 2016, at 21:15 , Marco S Hyman wrote:
>
>> Is there a way that avoids branching?
>
> Don’t know. Have you profiled
>
> let r = a > b ? 1 : 0
>
> to know it is an issue?
>>
>> So, according to Xcode, "true" a
> Is there a way that avoids branching?
Don’t know. Have you profiled
let r = a > b ? 1 : 0
to know it is an issue?
>
> So, according to Xcode, "true" and "a > b" both have type "Bool". I don't
> know why the compiler allows one and not the other, except that it's literal,
> and I guess ther
> On Nov 20, 2016, at 19:52 , Jon Shier wrote:
>
> Except in that case true isn’t a Bool but an NSNumber, which is why you can
> initialize an Int from it. It seems trivially easy to add an Int extension to
> do what you want though.
Is there a way that avoids branching?
So, according to Xco
Except in that case true isn’t a Bool but an NSNumber, which is why you can
initialize an Int from it. It seems trivially easy to add an Int extension to
do what you want though.
Jon
> On Nov 20, 2016, at 10:48 PM, Rick Mann via swift-users
> wrote:
>
> It seems I can't do this:
>
> let r
It seems I can't do this:
let r = Int(a > b)
but I can do it with a literal:
let r = Int(true)
I'd like to do this to implement signum without branching, but perhaps that's
not possible.
--
Rick Mann
rm...@latencyzero.com
___
swift-users mailing
17 matches
Mail list logo
