Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 8, 2016, at 11:15 AM, Dave Abrahams wrote: > on Wed Jun 08 2016, John McCall wrote: > >>> On Jun 7, 2016, at 4:25 PM, Dave Abrahams wrote: >>> on Tue Jun 07 2016, John McCall wrote: >>> > On Jun 5, 2016, at 5:18 PM, Dave Abrahams via

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

on Wed Jun 08 2016, John McCall wrote: >> On Jun 7, 2016, at 4:25 PM, Dave Abrahams wrote: >> on Tue Jun 07 2016, John McCall wrote: >> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution wrote: on Thu Jun 02 2016,

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 7, 2016, at 4:25 PM, Dave Abrahams wrote: > on Tue Jun 07 2016, John McCall wrote: > >>> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution >>> wrote: >>> on Thu Jun 02 2016, John McCall >>

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

on Tue Jun 07 2016, John McCall wrote: >> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution >> wrote: >> on Thu Jun 02 2016, John McCall > > wrote: >> >>> The official way to build a literal

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 4, 2016, at 11:54 AM, Chris Lattner wrote: > On Jun 2, 2016, at 9:08 AM, John McCall via swift-evolution > > wrote: >> >> The official way to build a literal of a specific type is to write the >> literal

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution > wrote: > on Thu Jun 02 2016, John McCall > wrote: > >> The official way to build a literal of a specific type is to write the >> literal

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

on Thu Jun 02 2016, John McCall wrote: > The official way to build a literal of a specific type is to write the > literal in an explicitly-typed context, like so: > let x: UInt16 = 7 > or > let x = 7 as UInt16 > > Nonetheless, programmers often try the

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

On Jun 2, 2016, at 9:08 AM, John McCall via swift-evolution wrote: > > The official way to build a literal of a specific type is to write the > literal in an explicitly-typed context, like so: > let x: UInt16 = 7 > or > let x = 7 as UInt16 > > Nonetheless,

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 4, 2016, at 10:27 AM, LM wrote: > > > > On Jun 4, 2016, at 4:00 PM, Matthew Johnson via swift-evolution > > wrote: > >> >>> On Jun 3, 2016, at 9:30 PM, John McCall >>

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 4, 2016, at 4:00 PM, Matthew Johnson via swift-evolution > wrote: > > >>> On Jun 3, 2016, at 9:30 PM, John McCall wrote: >>> On Jun 3, 2016, at 7:08 PM, Matthew Johnson wrote: > On Jun 3, 2016, at

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 9:30 PM, John McCall wrote: > >> On Jun 3, 2016, at 7:08 PM, Matthew Johnson wrote: >>> On Jun 3, 2016, at 8:11 PM, John McCall wrote: >>> On Jun 3, 2016, at 5:13 PM, Matthew Johnson

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 8:11 PM, Ben Rimmington wrote: > I think your original proposal is good, but just in case: > > [Currently] > >// Literal `7` is converted to `Swift.IntegerLiteralType` typealias. >UInt16(7) calls UInt16.init(_ value: Int) > > [Suggested] >

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 7:08 PM, Matthew Johnson wrote: >> On Jun 3, 2016, at 8:11 PM, John McCall wrote: >> >>> On Jun 3, 2016, at 5:13 PM, Matthew Johnson wrote: >>> On Jun 3, 2016, at 6:23 PM, John McCall

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 8:11 PM, John McCall wrote: > >> On Jun 3, 2016, at 5:13 PM, Matthew Johnson wrote: >> On Jun 3, 2016, at 6:23 PM, John McCall wrote: >> > On Jun 3, 2016, at 4:07 PM, David Sweeris

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 5:31 PM, Ben Rimmington via swift-evolution > wrote: > John McCall wrote: > >> I think that's a very promising way of thinking about literals. Writing >> a literal creates a notional value whose type is the informal, infinite- >> precise type of

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 5:13 PM, Matthew Johnson wrote: > On Jun 3, 2016, at 6:23 PM, John McCall wrote: > On Jun 3, 2016, at 4:07 PM, David Sweeris wrote: On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

John McCall wrote: > I think that's a very promising way of thinking about literals. Writing > a literal creates a notional value whose type is the informal, infinite- > precise type of all integer/FP/collection/etc. literals, which (1) can be > implicitly converted to any type that implements

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

Sent from my iPad On Jun 3, 2016, at 6:23 PM, John McCall wrote: >>> On Jun 3, 2016, at 4:07 PM, David Sweeris wrote: >>> On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution >>> wrote: >>> >>> Using an external

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

I would be very interested in seeing your original proposal presented for formal review. Austin On 6/3/16, John McCall via swift-evolution wrote: >> On Jun 3, 2016, at 4:07 PM, David Sweeris wrote: >>> On Jun 3, 2016, at 16:17, Matthew Johnson

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution > wrote: > > Using an external parameter label in a declaration and allowing it to be > omitted at the call site does not feel like the right answer to me. I think > we can find a better way to

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> I think our decision should be based upon which syntactic construct feels > least inconsistent with other similar syntactic constructs and therefore > feels the least arbitrary. Restricting the usage of a generic `Literal` type > to literal convertible initializers feels a little bit less

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 4:05 PM, Brent Royal-Gordon wrote: > >> I am not the only one who feels that way. Quoting Brent: >> >> "But if you're going to call `init(integerLiteral:)` like it's `init(_:)`, I >> don't think that's a good idea. Parameter labels are supposed to

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 3:17 PM, John McCall wrote: > >> On Jun 3, 2016, at 12:41 PM, Matthew Johnson > > wrote: >>> On Jun 3, 2016, at 1:36 PM, John McCall >> > wrote: >>>

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> I am not the only one who feels that way. Quoting Brent: > > "But if you're going to call `init(integerLiteral:)` like it's `init(_:)`, I > don't think that's a good idea. Parameter labels are supposed to be > significant; we don't want to lose that.” > > I agree with this. That is the

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 12:41 PM, Matthew Johnson wrote: >> On Jun 3, 2016, at 1:36 PM, John McCall > > wrote: >> >>> On Jun 2, 2016, at 6:48 PM, Matthew Johnson >> >

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

On Fri, Jun 3, 2016 at 2:41 PM, Matthew Johnson wrote: > > On Jun 3, 2016, at 1:36 PM, John McCall wrote: > > On Jun 2, 2016, at 6:48 PM, Matthew Johnson > wrote: > On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution <

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 1:36 PM, John McCall wrote: > >> On Jun 2, 2016, at 6:48 PM, Matthew Johnson > > wrote: >> On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution >>

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 10:31 PM, L. Mihalkovic > wrote: > On Jun 2, 2016, at 6:08 PM, John McCall via swift-evolution > > wrote: > >> The official way to build a literal of a specific type is to write the

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 6:48 PM, Matthew Johnson wrote: > On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution > > wrote: > >>> On Jun 2, 2016, at 4:33 PM, Xiaodi Wu >>

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 10:28 PM, Vladimir.S wrote: > > Like I said, the standard library and compiler conspire to make sure that > > easy cases like this are caught at compile time, but that would not help > > non-standard types that conform to IntegerLiteralConvertible. > > > >

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> I was referring to the subtle distinction between creating an Int32 from a > literal (the first one) and creating an Int from a literal and then > coercing it to Int32 (the second one). I understand the difference and just trying to find out if that behavior(Int32(x) vs x as Int32) could

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 6:08 PM, John McCall via swift-evolution > wrote: > > The official way to build a literal of a specific type is to write the > literal in an explicitly-typed context, like so: > let x: UInt16 = 7 > or > let x = 7 as UInt16 > >

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> Like I said, the standard library and compiler conspire to make sure that easy cases like this are caught at compile time, but that would not help non-standard types that conform to IntegerLiteralConvertible. > > Also, even for standard types, the syntax only works statically if the literal

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

Sent from my iPad >> On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution >> wrote: >> >> On Jun 2, 2016, at 4:33 PM, Xiaodi Wu wrote: >> The IntegerLiteral type idea might be worth exploring. It does seem to >> provide some additional

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 4:33 PM, Xiaodi Wu wrote: > The IntegerLiteral type idea might be worth exploring. It does seem to > provide some additional consistency. For example, wasn't it clarified on this > list just recently that literals don't have a type and adopt one based

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

The IntegerLiteral type idea might be worth exploring. It does seem to provide some additional consistency. For example, wasn't it clarified on this list just recently that literals don't have a type and adopt one based on context? It'd be nice to point out that 42 is an IntegerLiteral when

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1 It has nagged at me that this can happen even though I understood *why* it happens. On Thu, Jun 2, 2016 at 6:22 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 2, 2016, at 2:43 PM, Brent Royal-Gordon > wrote: > >> In my opinion,

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> So, you think that this syntax is enticing to new developers who naturally > think that the feature works the way that I'm proposing it should work, and > you think that the right solution is to make the syntax illegal so that you > can more conveniently tell them it doesn't work that way? :)

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 2:43 PM, Brent Royal-Gordon wrote: >> In my opinion, using this initializer-call syntax to build an >> explicitly-typed literal is an obvious and natural choice with several >> advantages over the "as" syntax. However, even if you disagree, it's

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 2:36 PM, Vladimir.S wrote: > Well, I understand that it seems like there is some problem with UIntN() > initialization, but can't find any simple code that will demonstrate this.. > > All below works as expected: > > var x1: Int32 = 0 > var x2 = Int32(0)

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

On Thu, Jun 2, 2016 at 2:38 PM Vladimir.S wrote: > What is wrong with your examples? > > var x1: Int32 = 0 > var x2 = Int32(0) > print(x1.dynamicType, x2.dynamicType) // Int32 Int32 > I was referring to the subtle distinction between creating an Int32 from a literal (the first

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

See, I've made this mistake as well, and *not* because I thought it casts the literal. I had always assumed that something like `UInt16(42)` would initialize using the integer literal init, since it seems logical that that's the most specific. The proposed change reflects my currently erroneous

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> In my opinion, using this initializer-call syntax to build an > explicitly-typed literal is an obvious and natural choice with several > advantages over the "as" syntax. However, even if you disagree, it's clear > that programmers are going to continue to independently try to use it, so >

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

What is wrong with your examples? var x1: Int32 = 0 var x2 = Int32(0) print(x1.dynamicType, x2.dynamicType) // Int32 Int32 On 03.06.2016 0:17, Tony Allevato via swift-evolution wrote: +1. As someone who thought "var x: Int32 = 0" and "var x = Int32(0)" were equivalent, this is very good to

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

Well, I understand that it seems like there is some problem with UIntN() initialization, but can't find any simple code that will demonstrate this.. All below works as expected: var x1: Int32 = 0 var x2 = Int32(0) print(x1.dynamicType, x2.dynamicType) // Int32 Int32 // integer overflows when

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 1:56 PM, Vladimir.S wrote: > > Often > > this leads to static ambiguities or, worse, causes the literal to be built > > using a default type (such as Int); this may have semantically very > > different results which are only caught at runtime. > > Seems

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1. As someone who thought "var x: Int32 = 0" and "var x = Int32(0)" were equivalent, this is very good to know (and very good to fix). I'm starting to wonder now if some of the times I've hit "expression was too complex" errors with large 64-bit multi-term expressions with literals were caused

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 9:08 AM, John McCall via swift-evolution > wrote: > > The official way to build a literal of a specific type is to write the > literal in an explicitly-typed context, like so: > let x: UInt16 = 7 > or > let x = 7 as UInt16 > >

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> Often > this leads to static ambiguities or, worse, causes the literal to be built > using a default type (such as Int); this may have semantically very > different results which are only caught at runtime. Seems like I'm very slow today.. Could you present a couple of examples where such

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

Sent from my iPad > On Jun 2, 2016, at 3:41 PM, John McCall wrote: > >>> On Jun 2, 2016, at 12:10 PM, Matthew Johnson wrote: >>> On Jun 2, 2016, at 1:46 PM, Austin Zheng via swift-evolution >>> wrote: >>> >>> +1. >>>

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

That makes sense. Thanks for sharing your reasoning. On Thu, Jun 2, 2016 at 1:38 PM, John McCall wrote: > On Jun 2, 2016, at 11:55 AM, Austin Zheng wrote: > I think we should actually go further. > > If this proposal is accepted, disallow "as" as a

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 12:10 PM, Matthew Johnson wrote: >> On Jun 2, 2016, at 1:46 PM, Austin Zheng via swift-evolution >> > wrote: >> >> +1. >> >> The primary advantage is that it aligns the language semantics

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 11:55 AM, Austin Zheng wrote: > I think we should actually go further. > > If this proposal is accepted, disallow "as" as a way of specifying the type > to construct from a literal. I see no reason to restrict "as" like this. We're not going to stop

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 12:57 PM, John McCall wrote: > >> On Jun 2, 2016, at 10:49 AM, David Sweeris > > wrote: >> I’m not entirely sure what an “expr-collection” is. > > Collection literals, e.g. [x,y,z] and [a: x, b: y].

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 1:55 PM, Austin Zheng via swift-evolution > wrote: > > I think we should actually go further. > > If this proposal is accepted, disallow "as" as a way of specifying the type > to construct from a literal. I’m not sure. I agree it would be bad

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

On Thu, Jun 2, 2016 at 12:11 PM, Xiaodi Wu wrote: > +1 to the proposal. I can also see the argument for disallowing multiple > ways of doing the same thing, though disallowing the use of `as` in this > way might be introducing another special case. > > The "as", "as?" and

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

Would it be possible to have a warning on usage if there is an ambiguity here? Otherwise, if we want T(0) to work, shouldn't we change the initializer signatures for LiteralConvertibles to match the desired behavior, rather than make it a special case? -DW > On Jun 2, 2016, at 1:57 PM, John

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1 to the proposal. I can also see the argument for disallowing multiple ways of doing the same thing, though disallowing the use of `as` in this way might be introducing another special case. If the proposal is accepted, I'd also advocate for the suggestion in the initial proposal to apply the

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 1:46 PM, Austin Zheng via swift-evolution > wrote: > > +1. > > The primary advantage is that it aligns the language semantics with how most > programmers expect this common C-language-family idiom to behave and removes > a potential source of

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

I think we should actually go further. If this proposal is accepted, disallow "as" as a way of specifying the type to construct from a literal. If this proposal isn't accepted, disallow using literal values as the argument to one-unlabeled-argument constructors. In either case we should

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1 l8r Sean > On Jun 2, 2016, at 1:46 PM, Austin Zheng via swift-evolution > wrote: > > +1. > > The primary advantage is that it aligns the language semantics with how most > programmers expect this common C-language-family idiom to behave and removes > a

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1. The primary advantage is that it aligns the language semantics with how most programmers expect this common C-language-family idiom to behave and removes a potential source of silently wrong code. The primary disadvantage is that it introduces special-case behavior to certain types of

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1 to this. It seems like a very straightforward thing to do. Sent from my iPad > On Jun 2, 2016, at 11:08 AM, John McCall via swift-evolution > wrote: > > The official way to build a literal of a specific type is to write the > literal in an explicitly-typed

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1 I have started using the ‘()’ syntax without even thinking about it. I never knew that it behaved in the way described. Using ‘()’ syntax will be natural for anyone with C++ experience. > On Jun 2, 2016, at 10:08 AM, John McCall via swift-evolution > wrote: >

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 10:49 AM, David Sweeris wrote: > I’m not entirely sure what an “expr-collection” is. Collection literals, e.g. [x,y,z] and [a: x, b: y]. > Does your proposal mean that in this code: > func foo() -> Int {...} > var w = 0 > var x = T(foo()) > var y = T(w)

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

I’m not entirely sure what an “expr-collection” is. Does your proposal mean that in this code: func foo() -> Int {...} var w = 0 var x = T(foo()) var y = T(w) var z = T(0) different initializers would be used for `x`,`y`, and `z`? If so, that seems a potential source of much subtler problems. I

[swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

The official way to build a literal of a specific type is to write the literal in an explicitly-typed context, like so: let x: UInt16 = 7 or let x = 7 as UInt16 Nonetheless, programmers often try the following: UInt16(7) Unfortunately, this does not attempt to construct the value