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]> 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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
