# \[Pitch\] Extending Swift Literals

**URL:** <https://forums.swift.org/t/pitch-extending-swift-literals/3353>\
**Category:** Pitches\
**Created:** [July 11, 2016, 3:48am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353 "2016-07-11T03:48:19Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\
**Post date:** [July 11, 2016, 3:48am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/1 "2016-07-11T03:48:19Z")

</div>

This is purely additive and would not be eligible for Swift 3.  
gist: [literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c)

-- E

Extending Swift Literals

Proposal: TBD  
Author: Erica Sadun \<[http://github.com/erica&gt](http://github.com/erica&gt);  
Status: TBD  
Review manager: TBD  
\<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#introduction&gt;Introduction)

This proposal expands Swift's language literals to include common cross-platform concepts that need not require.

\<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#motivation&gt;Motivation)

A Swift literal represents a fixed value in source code. A literal can be a string, a number (for example an integer), a compound value (such as an array), or one of several predefined "playground" literals including colors, resource file paths, and resource images.

Swift literals do not have types. They are universal representations that are evaluated and their types inferred from the context in which they are used. Because their nature is typeless, the same color literal can initialize UIColor, NSColor, and SKColor instances. The type cannot be inferred from the source without the context of its destination.

let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 0.4035313427, alpha: 1)  
\<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#detailed-design&gt;Detailed) Design

Namespace redesign  
Kind Literal Parameters  
Color `#literal.color(red:, green:, blue:, alpha:)` floating point values  
Image `#literal.image(resourceName:)` String with resource name  
File `#literal.file(resourceName:)` String with resource name  
General  
Kind Literal Parameters  
Sound `#literal.audio(resourceName:)` String with resource name  
URL `#literal.url(string:)`, `#literal.url(filePath:)` String with resource location  
Font `#literal.font(face:, size:)` string, floating point  
Date `#literal.date(timeInterval:)` floating point offset from Unix epoch  
Unicode `#literal.unicode(name:)` Official unicode name, e.g. `#literal.unicode(name:"DOG FACE")`  
Geometry  
Kind Literal Parameters  
Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`, `#literal.point(x:, y:, z:, w:)` floating point values  
Vector `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`, `#literal.vector(dx:, dy:, dz:, dw:)` floating point  
Size `#literal.size(width:, height:)`, `#literal.size(width:, height:, depth:)` floating point  
Rect `#literal.rect(x:, y:, width:, height:)` floating point  
Affine Transform `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`, `#literal.affineTransform(translateX:, translateY:)`, `#literal.affineTransform(scaleY:, scaleY:)`, `#literal.affineTransform(rotation:)`, floating point  
Bezier Path `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")` String with SVG path notation  
\<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#not-included&gt;Not) included:

Attributed Strings: I would like to see a way to define attributed strings (using some system like CSS/HTML) but could not think up a simple representation similar to the others mentioned in the preceding table.

JSON Literals: Again, probably too complex and possibly not worth their weight. If they could exist, they'd have to be imported via a resource or URL and transformed to a local type.

\<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#impact-on-existing-code&gt;Impact) on Existing Code

This proposal is purely additive.

\<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#alternatives-considered&gt;Alternatives) Considered

Using distinct literal names without subsuming them into a namespaced umbrella.

---

<div class="post-metadata">

**Author:** ![saagarjha](https://avatars.discourse-cdn.com/v4/letter/s/85f322/32.png) [@saagarjha](https://forums.swift.org/u/saagarjha)\
**Post date:** [July 11, 2016, 5:34am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/2 "2016-07-11T05:34:11Z")

</div>

Not completely sold on this one. First, the literal part is already pretty much implied, and I'd prefer dropping it as it feels too "heavyweight". The other, more serious issue was already partially touched upon by Xiaodi, that a lot of these are basically String representations. The Bezier path is an extreme example.

> **···**
>
> Sent from my Apple Watch
> 
> On Jul 10, 2016, at 20:48, Erica Sadun via swift-evolution \<swift-evolution@swift.org\> wrote:
> 
> > This is purely additive and would not be eligible for Swift 3.  
> > gist: [literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c)
> > 
> > -- E
> > 
> > Extending Swift Literals  
> > Proposal: TBD  
> > Author: Erica Sadun  
> > Status: TBD  
> > Review manager: TBD  
> > Introduction
> > 
> > This proposal expands Swift's language literals to include common cross-platform concepts that need not require.
> > 
> > Motivation
> > 
> > A Swift literal represents a fixed value in source code. A literal can be a string, a number (for example an integer), a compound value (such as an array), or one of several predefined "playground" literals including colors, resource file paths, and resource images.
> > 
> > Swift literals do not have types. They are universal representations that are evaluated and their types inferred from the context in which they are used. Because their nature is typeless, the same color literal can initialize UIColor, NSColor, and SKColor instances. The type cannot be inferred from the source without the context of its destination.
> > 
> > let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 0.4035313427, alpha: 1)  
> > Detailed Design
> > 
> > Namespace redesign  
> > Kind Literal Parameters  
> > Color `#literal.color(red:, green:, blue:, alpha:)` floating point values  
> > Image `#literal.image(resourceName:)` String with resource name  
> > File `#literal.file(resourceName:)` String with resource name  
> > General  
> > Kind Literal Parameters  
> > Sound `#literal.audio(resourceName:)` String with resource name  
> > URL `#literal.url(string:)`, `#literal.url(filePath:)` String with resource location  
> > Font `#literal.font(face:, size:)` string, floating point  
> > Date `#literal.date(timeInterval:)` floating point offset from Unix epoch  
> > Unicode `#literal.unicode(name:)` Official unicode name, e.g. `#literal.unicode(name:"DOG FACE")`  
> > Geometry  
> > Kind Literal Parameters  
> > Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`, `#literal.point(x:, y:, z:, w:)` floating point values  
> > Vector `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`, `#literal.vector(dx:, dy:, dz:, dw:)` floating point  
> > Size `#literal.size(width:, height:)`, `#literal.size(width:, height:, depth:)` floating point  
> > Rect `#literal.rect(x:, y:, width:, height:)` floating point  
> > Affine Transform `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`, `#literal.affineTransform(translateX:, translateY:)`, `#literal.affineTransform(scaleY:, scaleY:)`, `#literal.affineTransform(rotation:)`, floating point  
> > Bezier Path `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")` String with SVG path notation  
> > Not included:
> > 
> > Attributed Strings: I would like to see a way to define attributed strings (using some system like CSS/HTML) but could not think up a simple representation similar to the others mentioned in the preceding table.
> > 
> > JSON Literals: Again, probably too complex and possibly not worth their weight. If they could exist, they'd have to be imported via a resource or URL and transformed to a local type.
> > 
> > Impact on Existing Code
> > 
> > This proposal is purely additive.
> > 
> > Alternatives Considered
> > 
> > Using distinct literal names without subsuming them into a namespaced umbrella.  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![zwaldowski](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zwaldowski/32/21801_2.png) [@zwaldowski](https://forums.swift.org/u/zwaldowski)\
**Post date:** [July 11, 2016, 5:43am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/3 "2016-07-11T05:43:08Z")

</div>

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.

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'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.

Sincerely,  
&nbsp;&nbsp;Zachary Waldowski  
&nbsp;&nbsp;zach@waldowski.me

> **···**
>
> On Sun, Jul 10, 2016, at 08:48 PM, Erica Sadun via swift-evolution wrote:
> 
> > This is purely additive and would not be eligible for Swift 3.  
> > gist: [literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c)
> > 
> > -- E
> > 
> > Extending Swift Literals
> 
> > \* Proposal: TBD  
> > \* Author: Erica Sadun[1]  
> > \* Status: TBD  
> > \* Review manager: TBD  
> > Introduction  
> > This proposal expands Swift's language literals to include common cross-  
> > platform concepts that need not require.  
> > Motivation  
> > A Swift literal represents a fixed value in source code. A literal can  
> > be a string, a number (for example an integer), a compound value (such  
> > as an array), or one of several predefined "playground" literals  
> > including colors, resource file paths, and resource images.  
> > Swift literals do not have types. They are universal representations  
> > that are evaluated and their types inferred from the context in which  
> > they are used. Because their nature is typeless, the same color  
> > literal can initialize UIColor, NSColor, and SKColor instances. The  
> > type cannot be inferred from the source without the context of its  
> > destination.
> 
> > let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615,  
> > blue: 0.4035313427, alpha: 1)
> > 
> > Detailed Design
> 
> > \*Namespace redesign\*\*\* Kind Literal Parameters Color  
> > `#literal.color(red:, green:, blue:, alpha:)` floating point values  
> > Image `#literal.image(resourceName:)` String with resource name File  
> > `#literal.file(resourceName:)` String with resource name \*General\*\*\*  
> > Kind Literal Parameters Sound `#literal.audio(resourceName:)` String  
> > with resource name URL `#literal.url(string:)`,  
> > `#literal.url(filePath:)` String with resource location Font  
> > `#literal.font(face:, size:)` string, floating point Date  
> > `#literal.date(timeInterval:)` floating point offset from Unix epoch  
> > Unicode `#literal.unicode(name:)` Official unicode name, e.g.  
> > `#literal.unicode(name:"DOG FACE")` \*Geometry\*\*\* Kind Literal  
> > Parameters Point `#literal.point(x:, y:)`, `#literal.point(x:, y:,  
> > z:)`, `#literal.point(x:, y:, z:, w:)` floating point values Vector  
> > `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`,  
> > `#literal.vector(dx:, dy:, dz:, dw:)` floating point Size  
> > `#literal.size(width:, height:)`, `#literal.size(width:, height:,  
> > depth:)` floating point Rect `#literal.rect(x:, y:, width:, height:)`  
> > floating point Affine Transform  
> > `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`,  
> > `#literal.affineTransform(translateX:, translateY:)`,  
> > `#literal.affineTransform(scaleY:, scaleY:)`,  
> > `#literal.affineTransform(rotation:)`, floating point Bezier Path  
> > `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-  
> > 2.08 4z")` String with SVG path notation  
> > Not included:  
> > Attributed Strings: I would like to see a way to define attributed  
> > strings (using some system like CSS/HTML) but could not think up a  
> > simple representation similar to the others mentioned in the  
> > preceding table.  
> > JSON Literals: Again, probably too complex and possibly not worth  
> > their weight. If they could exist, they'd have to be imported via a  
> > resource or URL and transformed to a local type.  
> > Impact on Existing Code  
> > This proposal is purely additive.  
> > Alternatives Considered  
> > Using distinct literal names without subsuming them into a namespaced  
> > umbrella.  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> 
> Links:
> 
> &nbsp;&nbsp;1. [erica (Erica Sadun) · GitHub](http://github.com/erica)

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [July 11, 2016, 4:30am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/4 "2016-07-11T04:30:28Z")

</div>

Questions/comments--

What's your use case for these?

For proposed literals like `point`, I'm having trouble visualizing how that  
could be literally represented. Since the difference between one point and  
another is its coordinate, would we just see a point floating on the screen?

Something like `size` seems ill-suited for literal representation, as  
opposed to a shape (e.g. rectangle). Why is it a two-dimensional size  
anyway? Also, since literals have no type, is there any scenario in which a  
`size` literal of a certain width and height and a `point` literal with a  
certain x and y coordinate are meaningfully different?

Finally, several of these look like string literals with types. For  
instance, `unicode` seems to reflect a desire to refer to characters by  
their official names. Perhaps that could be proposed instead as a new  
escaping syntax for strings? Something like `let string = "\u{{DOG FACE}}"`  
might be pretty handy.

> **···**
>
> On Sun, Jul 10, 2016 at 10:48 PM, Erica Sadun via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > This is purely additive and would not be eligible for Swift 3.  
> > gist: [literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c)
> > 
> > -- E
> > 
> > Extending Swift Literals
> > 
> > &nbsp;&nbsp;&nbsp;- Proposal: TBD  
> > &nbsp;&nbsp;&nbsp;- Author: Erica Sadun \<[http://github.com/erica&gt](http://github.com/erica&gt);  
> > &nbsp;&nbsp;&nbsp;- Status: TBD  
> > &nbsp;&nbsp;&nbsp;- Review manager: TBD
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#introduction&gt);  
> > Introduction
> > 
> > This proposal expands Swift's language literals to include common  
> > cross-platform concepts that need not require.  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#motivation&gt);  
> > Motivation
> > 
> > A Swift literal represents a fixed value in source code. A literal can be  
> > a string, a number (for example an integer), a compound value (such as an  
> > array), or one of several predefined "playground" literals including  
> > colors, resource file paths, and resource images.
> > 
> > Swift literals do not have types. They are universal representations that  
> > are evaluated and their types inferred from the context in which they are  
> > used. Because their nature is typeless, the same color literal can  
> > initialize UIColor, NSColor, and SKColor instances. The type cannot be  
> > inferred from the source without the context of its destination.
> > 
> > let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 0.4035313427, alpha: 1)
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#detailed-design&gt;Detailed)  
> > Design  
> > \*Namespace redesign\*  
> > KindLiteralParameters  
> > Color `#literal.color(red:, green:, blue:, alpha:)` floating point values  
> > Image `#literal.image(resourceName:)` String with resource name  
> > File `#literal.file(resourceName:)` String with resource name  
> > \*General\*  
> > KindLiteralParameters  
> > Sound `#literal.audio(resourceName:)` String with resource name  
> > URL `#literal.url(string:)`, `#literal.url(filePath:)` String with  
> > resource location  
> > Font `#literal.font(face:, size:)` string, floating point  
> > Date `#literal.date(timeInterval:)` floating point offset from Unix epoch  
> > Unicode `#literal.unicode(name:)` Official unicode name, e.g.  
> > `#literal.unicode(name:"DOG FACE")`  
> > \*Geometry\*  
> > KindLiteralParameters  
> > Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`,  
> > `#literal.point(x:, y:, z:, w:)` floating point values  
> > Vector `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`,  
> > `#literal.vector(dx:, dy:, dz:, dw:)` floating point  
> > Size `#literal.size(width:, height:)`, `#literal.size(width:, height:,  
> > depth:)` floating point  
> > Rect `#literal.rect(x:, y:, width:, height:)` floating point  
> > Affine Transform `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`,  
> > `#literal.affineTransform(translateX:, translateY:)`,  
> > `#literal.affineTransform(scaleY:, scaleY:)`,  
> > `#literal.affineTransform(rotation:)`, floating point  
> > Bezier Path `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32,  
> > 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")` String with SVG  
> > path notation  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#not-included&gt;Not)  
> > included:
> > 
> > Attributed Strings: I would like to see a way to define attributed  
> > strings (using some system like CSS/HTML) but could not think up a simple  
> > representation similar to the others mentioned in the preceding table.
> > 
> > JSON Literals: Again, probably too complex and possibly not worth their  
> > weight. If they could exist, they'd have to be imported via a resource or  
> > URL and transformed to a local type.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#impact-on-existing-code&gt;Impact)  
> > on Existing Code
> > 
> > This proposal is purely additive.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#alternatives-considered&gt;Alternatives)  
> > Considered  
> > Using distinct literal names without subsuming them into a namespaced  
> > umbrella.
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\
**Post date:** [July 11, 2016, 6:41am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/5 "2016-07-11T06:41:13Z")

</div>

The existing literals are both few and pretty foundational to programming, so I don't mind them being slightly "magical". Rather than introducing another dozen "magic" types, wouldn't it be better to allow custom literal types, and have all these types use that system?

- Dave Sweeris

> **···**
>
> > On Jul 10, 2016, at 22:48, Erica Sadun via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > This is purely additive and would not be eligible for Swift 3.  
> > gist: [literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c)
> > 
> > -- E
> > 
> > Extending Swift Literals  
> > Proposal: TBD  
> > Author: Erica Sadun  
> > Status: TBD  
> > Review manager: TBD  
> > Introduction
> > 
> > This proposal expands Swift's language literals to include common cross-platform concepts that need not require.
> > 
> > Motivation
> > 
> > A Swift literal represents a fixed value in source code. A literal can be a string, a number (for example an integer), a compound value (such as an array), or one of several predefined "playground" literals including colors, resource file paths, and resource images.
> > 
> > Swift literals do not have types. They are universal representations that are evaluated and their types inferred from the context in which they are used. Because their nature is typeless, the same color literal can initialize UIColor, NSColor, and SKColor instances. The type cannot be inferred from the source without the context of its destination.
> > 
> > let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 0.4035313427, alpha: 1)  
> > Detailed Design
> > 
> > Namespace redesign  
> > Kind Literal Parameters  
> > Color `#literal.color(red:, green:, blue:, alpha:)` floating point values  
> > Image `#literal.image(resourceName:)` String with resource name  
> > File `#literal.file(resourceName:)` String with resource name  
> > General  
> > Kind Literal Parameters  
> > Sound `#literal.audio(resourceName:)` String with resource name  
> > URL `#literal.url(string:)`, `#literal.url(filePath:)` String with resource location  
> > Font `#literal.font(face:, size:)` string, floating point  
> > Date `#literal.date(timeInterval:)` floating point offset from Unix epoch  
> > Unicode `#literal.unicode(name:)` Official unicode name, e.g. `#literal.unicode(name:"DOG FACE")`  
> > Geometry  
> > Kind Literal Parameters  
> > Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`, `#literal.point(x:, y:, z:, w:)` floating point values  
> > Vector `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`, `#literal.vector(dx:, dy:, dz:, dw:)` floating point  
> > Size `#literal.size(width:, height:)`, `#literal.size(width:, height:, depth:)` floating point  
> > Rect `#literal.rect(x:, y:, width:, height:)` floating point  
> > Affine Transform `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`, `#literal.affineTransform(translateX:, translateY:)`, `#literal.affineTransform(scaleY:, scaleY:)`, `#literal.affineTransform(rotation:)`, floating point  
> > Bezier Path `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")` String with SVG path notation  
> > Not included:
> > 
> > Attributed Strings: I would like to see a way to define attributed strings (using some system like CSS/HTML) but could not think up a simple representation similar to the others mentioned in the preceding table.
> > 
> > JSON Literals: Again, probably too complex and possibly not worth their weight. If they could exist, they'd have to be imported via a resource or URL and transformed to a local type.
> > 
> > Impact on Existing Code
> > 
> > This proposal is purely additive.
> > 
> > Alternatives Considered
> > 
> > Using distinct literal names without subsuming them into a namespaced umbrella.  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Daniel\_Steinberg](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/daniel_steinberg/32/334_2.png) [@Daniel\_Steinberg](https://forums.swift.org/u/Daniel_Steinberg)\
**Post date:** [July 11, 2016, 11:57am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/6 "2016-07-11T11:57:51Z")

</div>

Perhaps I’m not thinking about literals correctly. I don’t think of them as something I can create in code using this syntax. I think of literals as something that I have a literal representation of. I can drag a color into Xcode or a playground. Same with an image.

In your proposal, I can imagine dragging in a URL from Safari or a webview or a sound file. I would support those two being added.

The geometry elements don’t seem to be in the same category of “thing”. Although I agree that Points and Rects can be a pain to construct, I can’t imagine what I’m dragging and dropping. If instead you want to use the literal syntax to construct one, then I’m definitely against this as that feels like a return to a stringly world in which we create things without compiler help.

Best,

Daniel

> **···**
>
> > On Jul 10, 2016, at 11:48 PM, Erica Sadun via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > This is purely additive and would not be eligible for Swift 3.  
> > gist: [literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c)
> > 
> > -- E
> > 
> > Extending Swift Literals
> > 
> > Proposal: TBD  
> > Author: Erica Sadun \<[http://github.com/erica&gt](http://github.com/erica&gt);  
> > Status: TBD  
> > Review manager: TBD  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#introduction&gt;Introduction)
> > 
> > This proposal expands Swift's language literals to include common cross-platform concepts that need not require.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#motivation&gt;Motivation)
> > 
> > A Swift literal represents a fixed value in source code. A literal can be a string, a number (for example an integer), a compound value (such as an array), or one of several predefined "playground" literals including colors, resource file paths, and resource images.
> > 
> > Swift literals do not have types. They are universal representations that are evaluated and their types inferred from the context in which they are used. Because their nature is typeless, the same color literal can initialize UIColor, NSColor, and SKColor instances. The type cannot be inferred from the source without the context of its destination.
> > 
> > let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 0.4035313427, alpha: 1)  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#detailed-design&gt;Detailed) Design
> > 
> > Namespace redesign  
> > Kind Literal Parameters  
> > Color `#literal.color(red:, green:, blue:, alpha:)` floating point values  
> > Image `#literal.image(resourceName:)` String with resource name  
> > File `#literal.file(resourceName:)` String with resource name  
> > General  
> > Kind Literal Parameters  
> > Sound `#literal.audio(resourceName:)` String with resource name  
> > URL `#literal.url(string:)`, `#literal.url(filePath:)` String with resource location  
> > Font `#literal.font(face:, size:)` string, floating point  
> > Date `#literal.date(timeInterval:)` floating point offset from Unix epoch  
> > Unicode `#literal.unicode(name:)` Official unicode name, e.g. `#literal.unicode(name:"DOG FACE")`  
> > Geometry  
> > Kind Literal Parameters  
> > Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`, `#literal.point(x:, y:, z:, w:)` floating point values  
> > Vector `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`, `#literal.vector(dx:, dy:, dz:, dw:)` floating point  
> > Size `#literal.size(width:, height:)`, `#literal.size(width:, height:, depth:)` floating point  
> > Rect `#literal.rect(x:, y:, width:, height:)` floating point  
> > Affine Transform `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`, `#literal.affineTransform(translateX:, translateY:)`, `#literal.affineTransform(scaleY:, scaleY:)`, `#literal.affineTransform(rotation:)`, floating point  
> > Bezier Path `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")` String with SVG path notation  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#not-included&gt;Not) included:
> > 
> > Attributed Strings: I would like to see a way to define attributed strings (using some system like CSS/HTML) but could not think up a simple representation similar to the others mentioned in the preceding table.
> > 
> > JSON Literals: Again, probably too complex and possibly not worth their weight. If they could exist, they'd have to be imported via a resource or URL and transformed to a local type.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#impact-on-existing-code&gt;Impact) on Existing Code
> > 
> > This proposal is purely additive.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#alternatives-considered&gt;Alternatives) Considered
> > 
> > Using distinct literal names without subsuming them into a namespaced umbrella.  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Charlie\_Monroe1](https://avatars.discourse-cdn.com/v4/letter/c/d6d6ee/32.png) [@Charlie\_Monroe1](https://forums.swift.org/u/Charlie_Monroe1)\
**Post date:** [July 11, 2016, 6:11am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/7 "2016-07-11T06:11:47Z")

</div>

Several notes:

- SKColor is a typealias for NS/UIColor.  
- There are other colorspaces beyond RGB. Within such a redesign, I'd personally vote for adding HSB, CMYK, Grayscale.  
- NSPoint is just a typealias for CGPoint, just like NSRect is CGRect, etc. - there is really no type inferring since it's all CG\* structs.  
- Image literals should also be able to define the bundle they are in?

Since you've mentioned in later posts that these are values without a type on their own, how would one make their point structure use this? E.g. if I decided to implement struct MyPoint, how would I make it be initializable from #literal.point as well? Or would this be only for the hand-picked types supported by the compiler directly? Sorry, if there are protocols for this, I don't have much Playground experience.

That said, I'd personally rather welcome some kind of unified cross-platform API over several concepts, e.g. Color, Image, being part of Swift's Foundation. Yes, many details are platform specific, but Swift could define a basic API (for retrieving RGB values, etc.) that NSColor and UIColor would inherit from or conform to. The same with images, defining some basic Image protocol that would define the basic image API (i.e. size property, init by name).

I'm not sure if this is something Swift should include, but for the future of the language, it would definitely make sense to include some semi-AppKit/UIKit, which would include some of the UI-related stuff - not a button or table view, that's very platform specific, but some basic stuff such as the aforementioned Color, Image that would really be factories for platform-specific objects...

> **···**
>
> > On Jul 11, 2016, at 5:48 AM, Erica Sadun via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > This is purely additive and would not be eligible for Swift 3.  
> > gist: [literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c)
> > 
> > -- E
> > 
> > Extending Swift Literals
> > 
> > Proposal: TBD  
> > Author: Erica Sadun \<[http://github.com/erica&gt](http://github.com/erica&gt);  
> > Status: TBD  
> > Review manager: TBD  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#introduction&gt;Introduction)
> > 
> > This proposal expands Swift's language literals to include common cross-platform concepts that need not require.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#motivation&gt;Motivation)
> > 
> > A Swift literal represents a fixed value in source code. A literal can be a string, a number (for example an integer), a compound value (such as an array), or one of several predefined "playground" literals including colors, resource file paths, and resource images.
> > 
> > Swift literals do not have types. They are universal representations that are evaluated and their types inferred from the context in which they are used. Because their nature is typeless, the same color literal can initialize UIColor, NSColor, and SKColor instances. The type cannot be inferred from the source without the context of its destination.
> > 
> > let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 0.4035313427, alpha: 1)  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#detailed-design&gt;Detailed) Design
> > 
> > Namespace redesign  
> > Kind Literal Parameters  
> > Color `#literal.color(red:, green:, blue:, alpha:)` floating point values  
> > Image `#literal.image(resourceName:)` String with resource name  
> > File `#literal.file(resourceName:)` String with resource name  
> > General  
> > Kind Literal Parameters  
> > Sound `#literal.audio(resourceName:)` String with resource name  
> > URL `#literal.url(string:)`, `#literal.url(filePath:)` String with resource location  
> > Font `#literal.font(face:, size:)` string, floating point  
> > Date `#literal.date(timeInterval:)` floating point offset from Unix epoch  
> > Unicode `#literal.unicode(name:)` Official unicode name, e.g. `#literal.unicode(name:"DOG FACE")`  
> > Geometry  
> > Kind Literal Parameters  
> > Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`, `#literal.point(x:, y:, z:, w:)` floating point values  
> > Vector `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`, `#literal.vector(dx:, dy:, dz:, dw:)` floating point  
> > Size `#literal.size(width:, height:)`, `#literal.size(width:, height:, depth:)` floating point  
> > Rect `#literal.rect(x:, y:, width:, height:)` floating point  
> > Affine Transform `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`, `#literal.affineTransform(translateX:, translateY:)`, `#literal.affineTransform(scaleY:, scaleY:)`, `#literal.affineTransform(rotation:)`, floating point  
> > Bezier Path `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")` String with SVG path notation  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#not-included&gt;Not) included:
> > 
> > Attributed Strings: I would like to see a way to define attributed strings (using some system like CSS/HTML) but could not think up a simple representation similar to the others mentioned in the preceding table.
> > 
> > JSON Literals: Again, probably too complex and possibly not worth their weight. If they could exist, they'd have to be imported via a resource or URL and transformed to a local type.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#impact-on-existing-code&gt;Impact) on Existing Code
> > 
> > This proposal is purely additive.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#alternatives-considered&gt;Alternatives) Considered
> > 
> > Using distinct literal names without subsuming them into a namespaced umbrella.  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\
**Post date:** [July 11, 2016, 4:56am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/8 "2016-07-11T04:56:00Z")

</div>

It doesn't have to be "represented". It can be used as `#literal.point(x: 3.5, y: 2.0)` without any "pretty" picture.

A literal offers a typeless universal value that can be interpreted by a conforming type as a representation of itself, so you can have:

let x: CGPoint = #literal.point(x: 3.5, y: 2.0)  
let x: NSPoint = #literal.point(x: 3.5, y: 2.0)  
let x: float2 = #literal.point(x: 3.5, y: 2.0)

-- E

> **···**
>
> > On Jul 10, 2016, at 10:30 PM, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:
> > 
> > Questions/comments--
> > 
> > What's your use case for these?
> > 
> > For proposed literals like `point`, I'm having trouble visualizing how that could be literally represented. Since the difference between one point and another is its coordinate, would we just see a point floating on the screen?
> > 
> > Something like `size` seems ill-suited for literal representation, as opposed to a shape (e.g. rectangle). Why is it a two-dimensional size anyway? Also, since literals have no type, is there any scenario in which a `size` literal of a certain width and height and a `point` literal with a certain x and y coordinate are meaningfully different?
> > 
> > Finally, several of these look like string literals with types. For instance, `unicode` seems to reflect a desire to refer to characters by their official names. Perhaps that could be proposed instead as a new escaping syntax for strings? Something like `let string = "\u{{DOG FACE}}"` might be pretty handy.

---

<div class="post-metadata">

**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\
**Post date:** [July 11, 2016, 5:53am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/9 "2016-07-11T05:53:42Z")

</div>

> 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.

> **···**
>
> On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution \<swift-evolution@swift.org\> wrote:

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [July 11, 2016, 6:42am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/10 "2016-07-11T06:42:19Z")

</div>

> The existing literals are both few and pretty foundational to programming,  
> so I don't mind them being slightly "magical". Rather than introducing  
> another dozen "magic" types, wouldn't it be better to allow custom literal  
> types, and have all these types use that system?

+1 to a design for that.

> **···**
>
> On Mon, Jul 11, 2016 at 1:41 AM, David Sweeris via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > - Dave Sweeris
> > 
> > On Jul 10, 2016, at 22:48, Erica Sadun via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > This is purely additive and would not be eligible for Swift 3.  
> > gist: [literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c)
> > 
> > -- E
> > 
> > Extending Swift Literals
> > 
> > &nbsp;&nbsp;&nbsp;- Proposal: TBD  
> > &nbsp;&nbsp;&nbsp;- Author: Erica Sadun \<[http://github.com/erica&gt](http://github.com/erica&gt);  
> > &nbsp;&nbsp;&nbsp;- Status: TBD  
> > &nbsp;&nbsp;&nbsp;- Review manager: TBD
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#introduction&gt);  
> > Introduction
> > 
> > This proposal expands Swift's language literals to include common  
> > cross-platform concepts that need not require.  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#motivation&gt);  
> > Motivation
> > 
> > A Swift literal represents a fixed value in source code. A literal can be  
> > a string, a number (for example an integer), a compound value (such as an  
> > array), or one of several predefined "playground" literals including  
> > colors, resource file paths, and resource images.
> > 
> > Swift literals do not have types. They are universal representations that  
> > are evaluated and their types inferred from the context in which they are  
> > used. Because their nature is typeless, the same color literal can  
> > initialize UIColor, NSColor, and SKColor instances. The type cannot be  
> > inferred from the source without the context of its destination.
> > 
> > let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 0.4035313427, alpha: 1)
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#detailed-design&gt;Detailed)  
> > Design  
> > \*Namespace redesign\*  
> > KindLiteralParameters  
> > Color `#literal.color(red:, green:, blue:, alpha:)` floating point values  
> > Image `#literal.image(resourceName:)` String with resource name  
> > File `#literal.file(resourceName:)` String with resource name  
> > \*General\*  
> > KindLiteralParameters  
> > Sound `#literal.audio(resourceName:)` String with resource name  
> > URL `#literal.url(string:)`, `#literal.url(filePath:)` String with  
> > resource location  
> > Font `#literal.font(face:, size:)` string, floating point  
> > Date `#literal.date(timeInterval:)` floating point offset from Unix epoch  
> > Unicode `#literal.unicode(name:)` Official unicode name, e.g.  
> > `#literal.unicode(name:"DOG FACE")`  
> > \*Geometry\*  
> > KindLiteralParameters  
> > Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`,  
> > `#literal.point(x:, y:, z:, w:)` floating point values  
> > Vector `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`,  
> > `#literal.vector(dx:, dy:, dz:, dw:)` floating point  
> > Size `#literal.size(width:, height:)`, `#literal.size(width:, height:,  
> > depth:)` floating point  
> > Rect `#literal.rect(x:, y:, width:, height:)` floating point  
> > Affine Transform `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`,  
> > `#literal.affineTransform(translateX:, translateY:)`,  
> > `#literal.affineTransform(scaleY:, scaleY:)`,  
> > `#literal.affineTransform(rotation:)`, floating point  
> > Bezier Path `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32,  
> > 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")` String with SVG  
> > path notation  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#not-included&gt;Not)  
> > included:
> > 
> > Attributed Strings: I would like to see a way to define attributed  
> > strings (using some system like CSS/HTML) but could not think up a simple  
> > representation similar to the others mentioned in the preceding table.
> > 
> > JSON Literals: Again, probably too complex and possibly not worth their  
> > weight. If they could exist, they'd have to be imported via a resource or  
> > URL and transformed to a local type.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#impact-on-existing-code&gt;Impact)  
> > on Existing Code
> > 
> > This proposal is purely additive.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#alternatives-considered&gt;Alternatives)  
> > Considered  
> > Using distinct literal names without subsuming them into a namespaced  
> > umbrella.
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [July 11, 2016, 5:01am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/11 "2016-07-11T05:01:36Z")

</div>

Well, in my book, a thing without a representation isn't really a  
'literal', which to me implies some degree of WYSIWYG :)

> **···**
>
> On Sun, Jul 10, 2016 at 23:56 Erica Sadun \<erica@ericasadun.com\> wrote:
> 
> > \> On Jul 10, 2016, at 10:30 PM, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:  
> > \>  
> > \> Questions/comments--  
> > \>  
> > \> What's your use case for these?  
> > \>  
> > \> For proposed literals like `point`, I'm having trouble visualizing how  
> > that could be literally represented. Since the difference between one point  
> > and another is its coordinate, would we just see a point floating on the  
> > screen?  
> > \>  
> > \> Something like `size` seems ill-suited for literal representation, as  
> > opposed to a shape (e.g. rectangle). Why is it a two-dimensional size  
> > anyway? Also, since literals have no type, is there any scenario in which a  
> > `size` literal of a certain width and height and a `point` literal with a  
> > certain x and y coordinate are meaningfully different?  
> > \>  
> > \> Finally, several of these look like string literals with types. For  
> > instance, `unicode` seems to reflect a desire to refer to characters by  
> > their official names. Perhaps that could be proposed instead as a new  
> > escaping syntax for strings? Something like `let string = "\u{{DOG FACE}}"`  
> > might be pretty handy.
> > 
> > It doesn't have to be "represented". It can be used as `#literal.point(x:  
> > 3.5, y: 2.0)` without any "pretty" picture.
> > 
> > A literal offers a typeless universal value that can be interpreted by a  
> > conforming type as a representation of itself, so you can have:
> > 
> > let x: CGPoint = #literal.point(x: 3.5, y: 2.0)  
> > let x: NSPoint = #literal.point(x: 3.5, y: 2.0)  
> > let x: float2 = #literal.point(x: 3.5, y: 2.0)
> > 
> > -- E

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [July 11, 2016, 6:15am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/12 "2016-07-11T06:15:46Z")

</div>

Right. I think if these things turn out to be sufficiently universal, I'd  
want full canonical types and not just literals from Swift.

I'm satisfied that there's now a first-class URL value type provided by  
Foundation, for instance, and there I fail to see what I would gain with a  
"URL literal" that I couldn't have with a string literal and a URL type.

> **···**
>
> On Mon, Jul 11, 2016 at 01:12 Charlie Monroe via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > Several notes:
> > 
> > - SKColor is a typealias for NS/UIColor.  
> > - There are other colorspaces beyond RGB. Within such a redesign, I'd  
> > personally vote for adding HSB, CMYK, Grayscale.  
> > - NSPoint is just a typealias for CGPoint, just like NSRect is CGRect,  
> > etc. - there is really no type inferring since it's all CG\* structs.  
> > - Image literals should also be able to define the bundle they are in?
> > 
> > Since you've mentioned in later posts that these are values without a type  
> > on their own, how would one make their point structure use this? E.g. if I  
> > decided to implement struct MyPoint, how would I make it be initializable  
> > from #literal.point as well? Or would this be only for the hand-picked  
> > types supported by the compiler directly? Sorry, if there are protocols for  
> > this, I don't have much Playground experience.
> > 
> > That said, I'd personally rather welcome some kind of unified  
> > cross-platform API over several concepts, e.g. Color, Image, being part of  
> > Swift's Foundation. Yes, many details are platform specific, but Swift  
> > could define a basic API (for retrieving RGB values, etc.) that NSColor and  
> > UIColor would inherit from or conform to. The same with images, defining  
> > some basic Image protocol that would define the basic image API (i.e. size  
> > property, init by name).
> > 
> > I'm not sure if this is something Swift should include, but for the future  
> > of the language, it would definitely make sense to include some  
> > semi-AppKit/UIKit, which would include some of the UI-related stuff - not a  
> > button or table view, that's very platform specific, but some basic stuff  
> > such as the aforementioned Color, Image that would really be factories for  
> > platform-specific objects...
> > 
> > On Jul 11, 2016, at 5:48 AM, Erica Sadun via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > This is purely additive and would not be eligible for Swift 3.  
> > gist: [literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c)
> > 
> > -- E
> > 
> > Extending Swift Literals
> > 
> > &nbsp;&nbsp;&nbsp;- Proposal: TBD  
> > &nbsp;&nbsp;&nbsp;- Author: Erica Sadun \<[http://github.com/erica&gt](http://github.com/erica&gt);  
> > &nbsp;&nbsp;&nbsp;- Status: TBD  
> > &nbsp;&nbsp;&nbsp;- Review manager: TBD
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#introduction&gt);  
> > Introduction
> > 
> > This proposal expands Swift's language literals to include common  
> > cross-platform concepts that need not require.  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#motivation&gt);  
> > Motivation
> > 
> > A Swift literal represents a fixed value in source code. A literal can be  
> > a string, a number (for example an integer), a compound value (such as an  
> > array), or one of several predefined "playground" literals including  
> > colors, resource file paths, and resource images.
> > 
> > Swift literals do not have types. They are universal representations that  
> > are evaluated and their types inferred from the context in which they are  
> > used. Because their nature is typeless, the same color literal can  
> > initialize UIColor, NSColor, and SKColor instances. The type cannot be  
> > inferred from the source without the context of its destination.
> > 
> > let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 0.4035313427, alpha: 1)
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#detailed-design&gt;Detailed)  
> > Design  
> > \*Namespace redesign\*  
> > KindLiteralParameters  
> > Color `#literal.color(red:, green:, blue:, alpha:)` floating point values  
> > Image `#literal.image(resourceName:)` String with resource name  
> > File `#literal.file(resourceName:)` String with resource name  
> > \*General\*  
> > KindLiteralParameters  
> > Sound `#literal.audio(resourceName:)` String with resource name  
> > URL `#literal.url(string:)`, `#literal.url(filePath:)` String with  
> > resource location  
> > Font `#literal.font(face:, size:)` string, floating point  
> > Date `#literal.date(timeInterval:)` floating point offset from Unix epoch  
> > Unicode `#literal.unicode(name:)` Official unicode name, e.g.  
> > `#literal.unicode(name:"DOG FACE")`  
> > \*Geometry\*  
> > KindLiteralParameters  
> > Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`,  
> > `#literal.point(x:, y:, z:, w:)` floating point values  
> > Vector `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`,  
> > `#literal.vector(dx:, dy:, dz:, dw:)` floating point  
> > Size `#literal.size(width:, height:)`, `#literal.size(width:, height:,  
> > depth:)` floating point  
> > Rect `#literal.rect(x:, y:, width:, height:)` floating point  
> > Affine Transform `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`,  
> > `#literal.affineTransform(translateX:, translateY:)`,  
> > `#literal.affineTransform(scaleY:, scaleY:)`,  
> > `#literal.affineTransform(rotation:)`, floating point  
> > Bezier Path `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32,  
> > 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")` String with SVG  
> > path notation  
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#not-included&gt;Not)  
> > included:
> > 
> > Attributed Strings: I would like to see a way to define attributed  
> > strings (using some system like CSS/HTML) but could not think up a simple  
> > representation similar to the others mentioned in the preceding table.
> > 
> > JSON Literals: Again, probably too complex and possibly not worth their  
> > weight. If they could exist, they'd have to be imported via a resource or  
> > URL and transformed to a local type.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#impact-on-existing-code&gt;Impact)  
> > on Existing Code
> > 
> > This proposal is purely additive.
> > 
> > \<[literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#alternatives-considered&gt;Alternatives)  
> > Considered  
> > Using distinct literal names without subsuming them into a namespaced  
> > umbrella.  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [July 11, 2016, 12:57pm UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/13 "2016-07-11T12:57:05Z")

</div>

> Several notes:
> 
> - SKColor is a typealias for NS/UIColor.  
> - There are other colorspaces beyond RGB. Within such a redesign, I'd personally vote for adding HSB, CMYK, Grayscale.

It's also important to distinguish RGN color spaces (i.e. sRGB vs P3).

> **···**
>
> Sent from my iPad
> 
> > On Jul 11, 2016, at 1:11 AM, Charlie Monroe via swift-evolution \<swift-evolution@swift.org\> wrote:
> 
> > - NSPoint is just a typealias for CGPoint, just like NSRect is CGRect, etc. - there is really no type inferring since it's all CG\* structs.  
> > - Image literals should also be able to define the bundle they are in?
> > 
> > Since you've mentioned in later posts that these are values without a type on their own, how would one make their point structure use this? E.g. if I decided to implement struct MyPoint, how would I make it be initializable from #literal.point as well? Or would this be only for the hand-picked types supported by the compiler directly? Sorry, if there are protocols for this, I don't have much Playground experience.
> > 
> > That said, I'd personally rather welcome some kind of unified cross-platform API over several concepts, e.g. Color, Image, being part of Swift's Foundation. Yes, many details are platform specific, but Swift could define a basic API (for retrieving RGB values, etc.) that NSColor and UIColor would inherit from or conform to. The same with images, defining some basic Image protocol that would define the basic image API (i.e. size property, init by name)
> > 
> > I'm not sure if this is something Swift should include, but for the future of the language, it would definitely make sense to include some semi-AppKit/UIKit, which would include some of the UI-related stuff - not a button or table view, that's very platform specific, but some basic stuff such as the aforementioned Color, Image that would really be factories for platform-specific objects...
> > 
> > > On Jul 11, 2016, at 5:48 AM, Erica Sadun via swift-evolution \<swift-evolution@swift.org\> wrote:
> > > 
> > > This is purely additive and would not be eligible for Swift 3.  
> > > gist: [literals.md · GitHub](https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c)
> > > 
> > > -- E
> > > 
> > > Extending Swift Literals  
> > > Proposal: TBD  
> > > Author: Erica Sadun  
> > > Status: TBD  
> > > Review manager: TBD  
> > > Introduction
> > > 
> > > This proposal expands Swift's language literals to include common cross-platform concepts that need not require.
> > > 
> > > Motivation
> > > 
> > > A Swift literal represents a fixed value in source code. A literal can be a string, a number (for example an integer), a compound value (such as an array), or one of several predefined "playground" literals including colors, resource file paths, and resource images.
> > > 
> > > Swift literals do not have types. They are universal representations that are evaluated and their types inferred from the context in which they are used. Because their nature is typeless, the same color literal can initialize UIColor, NSColor, and SKColor instances. The type cannot be inferred from the source without the context of its destination.
> > > 
> > > let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 0.4035313427, alpha: 1)  
> > > Detailed Design
> > > 
> > > Namespace redesign  
> > > Kind Literal Parameters  
> > > Color `#literal.color(red:, green:, blue:, alpha:)` floating point values  
> > > Image `#literal.image(resourceName:)` String with resource name  
> > > File `#literal.file(resourceName:)` String with resource name  
> > > General  
> > > Kind Literal Parameters  
> > > Sound `#literal.audio(resourceName:)` String with resource name  
> > > URL `#literal.url(string:)`, `#literal.url(filePath:)` String with resource location  
> > > Font `#literal.font(face:, size:)` string, floating point  
> > > Date `#literal.date(timeInterval:)` floating point offset from Unix epoch  
> > > Unicode `#literal.unicode(name:)` Official unicode name, e.g. `#literal.unicode(name:"DOG FACE")`  
> > > Geometry  
> > > Kind Literal Parameters  
> > > Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`, `#literal.point(x:, y:, z:, w:)` floating point values  
> > > Vector `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`, `#literal.vector(dx:, dy:, dz:, dw:)` floating point  
> > > Size `#literal.size(width:, height:)`, `#literal.size(width:, height:, depth:)` floating point  
> > > Rect `#literal.rect(x:, y:, width:, height:)` floating point  
> > > Affine Transform `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`, `#literal.affineTransform(translateX:, translateY:)`, `#literal.affineTransform(scaleY:, scaleY:)`, `#literal.affineTransform(rotation:)`, floating point  
> > > Bezier Path `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")` String with SVG path notation  
> > > Not included:
> > > 
> > > Attributed Strings: I would like to see a way to define attributed strings (using some system like CSS/HTML) but could not think up a simple representation similar to the others mentioned in the preceding table.
> > > 
> > > JSON Literals: Again, probably too complex and possibly not worth their weight. If they could exist, they'd have to be imported via a resource or URL and transformed to a local type.
> > > 
> > > Impact on Existing Code
> > > 
> > > This proposal is purely additive.
> > > 
> > > Alternatives Considered
> > > 
> > > Using distinct literal names without subsuming them into a namespaced umbrella.  
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [July 11, 2016, 6:01am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/14 "2016-07-11T06:01:35Z")

</div>

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.

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.

> **···**
>
> On Mon, Jul 11, 2016 at 00:53 Erica Sadun via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution \< \> swift-evolution@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@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Daniel\_Steinberg](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/daniel_steinberg/32/334_2.png) [@Daniel\_Steinberg](https://forums.swift.org/u/Daniel_Steinberg)\
**Post date:** [July 11, 2016, 12:03pm UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/15 "2016-07-11T12:03:32Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![gmosx](https://avatars.discourse-cdn.com/v4/letter/g/fbc32d/32.png) [@gmosx](https://forums.swift.org/u/gmosx)\
**Post date:** [July 11, 2016, 8:54pm UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/16 "2016-07-11T20:54:45Z")

</div>

> Right. I think if these things turn out to be sufficiently universal, I'd want full canonical types and not just literals from Swift.

+1

---

<div class="post-metadata">

**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\
**Post date:** [July 11, 2016, 6:07am UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/17 "2016-07-11T06:07:28Z")

</div>

I'm going to argue that these things are universal, just as applicable to Linux/Windows/etc platforms as they are to the Cocoasphere.

-- E

> **···**
>
> > On Jul 11, 2016, at 12:01 AM, Xiaodi Wu \<xiaodi.wu@gmail.com\> wrote:
> > 
> > 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.
> > 
> > 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.
> > 
> > On Mon, Jul 11, 2016 at 00:53 Erica Sadun via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:  
> > On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@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@swift.org \<mailto:swift-evolution@swift.org\>  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Lmpessoa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lmpessoa/32/19771_2.png) [@Lmpessoa](https://forums.swift.org/u/Lmpessoa)\
**Post date:** [July 11, 2016, 12:38pm UTC](https://forums.swift.org/t/pitch-extending-swift-literals/3353/18 "2016-07-11T12:38:30Z")

</div>

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