(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 >> <[email protected] <mailto:[email protected]>> wrote: >> >> On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution >> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
