[swift-evolution] [Pitch] Extending Swift Literals

Leonardo Pessoa me at lmpessoa.com
Mon Jul 11 07:38:30 CDT 2016


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>


More information about the swift-evolution mailing list