[swift-evolution] [Pitch] Extending Swift Literals

[Charlie Monroe]

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 at swift.org> wrote:
> 
> This is purely additive and would not be eligible for Swift 3. 
> gist: https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c <https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c>
> 
> -- E
> 
> Extending Swift Literals
> 
> Proposal: TBD
> Author: Erica Sadun <http://github.com/erica>
> Status: TBD
> Review manager: TBD
>  <https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#introduction>Introduction
> 
> This proposal expands Swift's language literals to include common cross-platform concepts that need not require.
> 
>  <https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#motivation>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)
>  <https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#detailed-design>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
>  <https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#not-included>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.
> 
>  <https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#impact-on-existing-code>Impact on Existing Code
> 
> This proposal is purely additive.
> 
>  <https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c#alternatives-considered>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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/15094c67/attachment.html>