I'm also not in for this. As mentioned before, these don't seem like literals but some sort of masking shortcut to other framework's calls to create the given objects. I think I could go only for colour literals here but if its literal representation were something close to HTML's.<div><br></div><div>L<br><br>On Monday, 11 July 2016, Daniel Steinberg via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">(Forgot to copy the list)<div><br><div><blockquote type="cite"><div><div style="word-wrap:break-word"></div></div></blockquote><div><div style="word-wrap:break-word">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. <div><br></div><div>Although literals have this benefit, that seems to be a secondary feature of them to me.</div><div><br></div><div>Wanting that aspect of literals is, in my opinion, an API request not a language request.</div><div><br></div><div>Best,</div><div><br></div><div>Daniel</div></div></div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div><br><div><blockquote type="cite"><div>On Jul 11, 2016, at 1:53 AM, Erica Sadun via swift-evolution <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word">On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>> wrote:<br><div><blockquote type="cite"><br><div>
<div><div style="font-family:Arial">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.<br></div></div></div></blockquote><div><br></div>Literals enable you to write cross platform code with a minimum of </div><div>redundant and platform-configured code.</div><div><br></div><div>In today's Swift, you can say: let myColor = color literal and that code is </div><div>cross-compatible for all Apple platforms, whether UIColor, NSColor, and SKColor.</div><div>If you write that same request as let myColor = UIColor(...), it will no longer </div><div>compile on Cocoa.</div><div><br></div><div>I'm proposing to extend these existing behaviors to create common code inherently </div><div>universal tasks with common structure: NSFont/UIFont, point2/CGPoint/NSPoint, etc</div><div><br></div><div><blockquote type="cite"><div><div>
<div style="font-family:Arial">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.</div></div></div></blockquote><div><br></div>I've already filed radars asking that the code editor let you see the raw unrendered literals</div><div>and heartily encourage duped radars to support that end.</div><div><br><blockquote type="cite"><div><div><div style="font-family:Arial"> 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.</div></div></div></blockquote><div><br></div><div>The core team has suggested they'd like to use namespacing, especially with related</div><div>items that could otherwise spread and grow in an unmanaged way.</div></div><br></div>_______________________________________________<br>swift-evolution mailing list<br><a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></blockquote></div><br><br>-- <br>L<br>