On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution 
<swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to