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.
L On Monday, 11 July 2016, Daniel Steinberg via swift-evolution < [email protected]> wrote: > (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] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution < > [email protected] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > -- L
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
