[swift-evolution] [Pitch] Extending Swift Literals

[Xiaodi Wu]

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 at 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 at swift.org> 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 <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*
> 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
> <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
>
>
> _______________________________________________
> 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/61d8bc3d/attachment.html>