Ahh, misunderstanding then. I had thought they were suggesting this was the default value of the typealias.
Thanks for clearing that up, Jaden Geller > On Mar 11, 2017, at 5:08 PM, Robert Widmann <[email protected]> wrote: > > You may be missing/misspelling the typealias declaration. This has been in > Policy.swift for a while now, and I can reproduce this as far back as 2.2 in > the Bluemix sandbox. > > ~Robert Widmann > >> On Mar 11, 2017, at 7:41 PM, Jaden Geller via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> On Mar 11, 2017, at 3:22 PM, Ben Cohen <[email protected] >>> <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
