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