<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">(Forgot to copy the list)<div class=""><br class=""><div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""></div></div></blockquote><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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 class=""><br class=""></div><div class="">Although literals have this benefit, that seems to be a secondary feature of them to me.</div><div class=""><br class=""></div><div class="">Wanting that aspect of literals is, in my opinion, an API request not a language request.</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">Daniel</div></div></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 11, 2016, at 1:53 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class="">
<title class=""></title>
<div class=""><div style="font-family:Arial;" class="">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 class=""></div></div></div></blockquote><div class=""><br class=""></div>Literals enable you to write cross platform code with a minimum of </div><div class="">redundant and platform-configured code.</div><div class=""><br class=""></div><div class="">In today's Swift, you can say: let myColor = color literal and that code is </div><div class="">cross-compatible for all Apple platforms, whether UIColor, NSColor, and SKColor.</div><div class="">If you write that same request as let myColor = UIColor(...), it will no longer </div><div class="">compile on Cocoa.</div><div class=""><br class=""></div><div class="">I'm proposing to extend these existing behaviors to create common code inherently </div><div class="">universal tasks with common structure: NSFont/UIFont, point2/CGPoint/NSPoint, etc</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="">
<div style="font-family:Arial;" class="">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 class=""><br class=""></div>I've already filed radars asking that the code editor let you see the raw unrendered literals</div><div class="">and heartily encourage duped radars to support that end.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div style="font-family:Arial;" class=""> 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 class=""><br class=""></div><div class="">The core team has suggested they'd like to use namespacing, especially with related</div><div class="">items that could otherwise spread and grow in an unmanaged way.</div></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>