[Pitch] Extending Swift Literals

Erica_Sadun · 2016-07-11T03:48:19.000Z

This is purely additive and would not be eligible for Swift 3.
gist: literals.md · GitHub

-- E

Extending Swift Literals

Proposal: TBD
Author: Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD
<literals.md · GitHub

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

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 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 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 on Existing Code

This proposal is purely additive.

<literals.md · GitHub Considered

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

saagarjha · 2016-07-11T05:34:11.000Z

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

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

zwaldowski · 2016-07-11T05:43:08.000Z

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,
Zachary Waldowski
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

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

Links:

1. erica (Erica Sadun) · GitHub

xwu · 2016-07-11T04:30:28.000Z

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

-- E

Extending Swift Literals

   - Proposal: TBD
   - Author: Erica Sadun <http://github.com/erica>
   - Status: TBD
   - Review manager: TBD

<literals.md · GitHub;
Introduction

This proposal expands Swift's language literals to include common
cross-platform concepts that need not require.
<literals.md · GitHub;
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
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
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
on Existing Code

This proposal is purely additive.

<literals.md · GitHub
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

David_Sweeris · 2016-07-11T06:41:13.000Z

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

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

Daniel_Steinberg · 2016-07-11T11:57:51.000Z

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

-- E

Extending Swift Literals

Proposal: TBD
Author: Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD
<literals.md · GitHub

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

<literals.md · GitHub

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 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 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 on Existing Code

This proposal is purely additive.

<literals.md · GitHub 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

Charlie_Monroe1 · 2016-07-11T06:11:47.000Z

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

-- E

Extending Swift Literals

Proposal: TBD
Author: Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD
<literals.md · GitHub

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

<literals.md · GitHub

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 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 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 on Existing Code

This proposal is purely additive.

<literals.md · GitHub 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

Erica_Sadun · 2016-07-11T04:56:00.000Z

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.

Erica_Sadun · 2016-07-11T05:53:42.000Z

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:

xwu · 2016-07-11T06:42:19.000Z

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

-- E

Extending Swift Literals

   - Proposal: TBD
   - Author: Erica Sadun <http://github.com/erica>
   - Status: TBD
   - Review manager: TBD

<literals.md · GitHub;
Introduction

This proposal expands Swift's language literals to include common
cross-platform concepts that need not require.
<literals.md · GitHub;
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
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
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
on Existing Code

This proposal is purely additive.

<literals.md · GitHub
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · 2016-07-11T05:01:36.000Z

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

xwu · 2016-07-11T06:15:46.000Z

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

-- E

Extending Swift Literals

   - Proposal: TBD
   - Author: Erica Sadun <http://github.com/erica>
   - Status: TBD
   - Review manager: TBD

<literals.md · GitHub;
Introduction

This proposal expands Swift's language literals to include common
cross-platform concepts that need not require.
<literals.md · GitHub;
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
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
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
on Existing Code

This proposal is purely additive.

<literals.md · GitHub
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

anandabits · 2016-07-11T12:57:05.000Z

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

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · 2016-07-11T06:01:35.000Z

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

Daniel_Steinberg · 2016-07-11T12:03:32.000Z

(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

gmosx · 2016-07-11T20:54:45.000Z

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

Erica_Sadun · 2016-07-11T06:07:28.000Z

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

Lmpessoa · 2016-07-11T12:38:30.000Z

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

--
L