> On Mar 11, 2017, at 3:22 PM, Ben Cohen <[email protected]> wrote:
> 
>> 
>> On Mar 11, 2017, at 1:17 PM, Jaden Geller via swift-evolution 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>> 
>> 
>> On Mar 11, 2017, at 12:20 PM, David Sweeris via swift-evolution 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>>> 
>>>> On Mar 11, 2017, at 12:57 AM, Jean-Daniel via swift-evolution 
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>> 
>>>> -1
>>>> 
>>>> It would be inconsistent to allow it for deterministic literals (String) 
>>>> and not for non deterministic literal (int which can be either a Int, 
>>>> Uint, Float, …)
>>> 
>>> If I’m not mistaken, even with `bar = “baz”`, `String` is merely the 
>>> default inferred type. It could be anything that conforms to 
>>> `ExpressibleByStringLiteral`, right? In that regard, this is kinda just a 
>>> way to make a function implicitly generic:
>>> func foo(bar = "baz") {…}
>>> becomes:
>>> func foo<T: ExpressibleByStringLiteral>(bar: T = "baz") {…}
>>> 
>> 
>> As I understood it, omitting the type would work identically to `let` 
>> declarations. A string literal without a type defaults to `String`. Treating 
>> it as a generic function is a bad idea IMO.
>> 
> 
> More specifically, a string literal without a type defaults to the 
> StringLiteralType typealias:
> 
> typealias StringLiteralType = StaticString
> let s = "abc"
> print(type(of: s))
> // prints StaticString

What version of the Swift compiler are you using? I don’t observe this 
behavior. That code prints `String` for me.

> 
>> I don't think this sugar is worth any amount of added complexity. Most 
>> function arguments will have not have default values and this have to 
>> continue to declare the type, so this would only be more concise in very few 
>> cases. I'd prefer the consistency of always having to explicitly declare the 
>> argument type at a function boundary.
>> 
>> To call a function, you need to know what type to pass in. This becomes more 
>> difficult when not make explicit, particularly when a more complicated 
>> expression is used as a default. -1
>> 
>>> Is there anything we can do with a variable, if all we know of it is that 
>>> it conforms to `ExpressibleByStringLiteral`? I can’t think of anything… If 
>>> we had a way to get back the literal string which the variable was 
>>> initialized with, we could initialize other values with that, but the 
>>> protocol doesn’t require us to store it. Come to think of it, is there even 
>>> a way to store a literal value in its “untyped” form? You can declare a 
>>> variable to of type `IntegerLiteralType`, but the type system then treats 
>>> it as an `Int`.
>>> 
>>> So while it looks nice (to me, anyway) I’m not sure you could actually do 
>>> anything with it. Or am I looking at this wrong?
>>> 
>>> - Dave Sweeris
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to