[swift-evolution] [Pitch] Extending Swift Literals

[Daniel Steinberg]

(Forgot to copy the list)

If what you’re after is cross platform code, then I would rather see types such as Color be standardized to represent a UIColor/NSColor on the appropriate platform. 

Although literals have this benefit, that seems to be a secondary feature of them to me.

Wanting that aspect of literals is, in my opinion, an API request not a language request.

Best,

Daniel
> 
> 
>> On Jul 11, 2016, at 1:53 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> I share the concern with others about the usefulness of these, but I also like your note about standardizing syntax, and really like that these merge together all the different syntaxes for literals we've seen.
>> 
>> Literals enable you to write cross platform code with a minimum of 
>> redundant and platform-configured code.
>> 
>> In today's Swift, you can say:   let myColor = color literal and that code is 
>> cross-compatible for all Apple platforms, whether UIColor, NSColor, and SKColor.
>> If you write that same request as let myColor = UIColor(...), it will no longer 
>> compile on Cocoa.
>> 
>> I'm proposing to extend these existing behaviors to create common code inherently 
>> universal tasks with common structure: NSFont/UIFont, point2/CGPoint/NSPoint, etc
>> 
>>> To that end, I'd like to modestly suggest that #literal.foo (as already written in the proposal) should be the canonical form of a literal in source text, whereas #foo is the one you see used in the code editor.
>> 
>> I've already filed radars asking that the code editor let you see the raw unrendered literals
>> and heartily encourage duped radars to support that end.
>> 
>>> I'm not a fan of namespacing in #literal, because every literal should obviously be a literal; I wouldn't ever recommend numerals fall under this proposal as written, for instance.
>> 
>> The core team has suggested they'd like to use namespacing, especially with related
>> items that could otherwise spread and grow in an unmanaged way.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/d97c1c68/attachment.html>