Sent from my iPad
> On Jul 11, 2016, at 1:11 AM, 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. It's also important to distinguish RGN color spaces (i.e. sRGB vs P3). > - 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 >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
