[swift-evolution] [Pitch] Extending Swift Literals

[Zach Waldowski]

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 at 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: 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 

Links:

  1. http://github.com/erica
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160710/950bb44f/attachment.html>