[swift-evolution] [Pitch] Extending Swift Literals

[Leonardo Pessoa]

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 <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
> On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> 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
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>

-- 
L
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/d82976f8/attachment.html>