<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I'm going to argue that these things are universal, just as applicable to Linux/Windows/etc platforms as they are to the Cocoasphere. </div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jul 11, 2016, at 12:01 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="white-space:pre-wrap" class="">Ah. Now I see the use case. I'd counter, however, that these are weaknesses of the respective frameworks, and that literals as you propose them are rather like a thin version (in the motivating problem it's trying to solve) of the longed-for UXKit that'll supposedly unify all.<br class=""><br class="">Even if we have these proposed literals, the various Apple-proprietary frameworks would have to be modified to accept them (to be expressible by them, in the new parlance). We could equally well appeal for the frameworks to be modified so that NS* types and UI* types play nicely together, without providing these pan-Swift facilities. Server code, for instance, could have little need for a font literal.<br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jul 11, 2016 at 00:53 Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><br class=""><div class="">
<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></div></div><div style="word-wrap:break-word" class=""><div class="">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=""></div></div><div style="word-wrap:break-word" class=""><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></div></div><div style="word-wrap:break-word" class=""><div class="">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=""></div></div><div style="word-wrap:break-word" class=""><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></div><div style="word-wrap:break-word" class=""><div class=""><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" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>