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 
<[email protected]> 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
> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to