I'm going to argue that these things are universal, just as applicable to Linux/Windows/etc platforms as they are to the Cocoasphere.
-- E > On Jul 11, 2016, at 12:01 AM, Xiaodi Wu <[email protected]> wrote: > > Ah. Now I see the use case. I'd counter, however, that these are weaknesses > of the respective frameworks, and that literals as you propose them are > rather like a thin version (in the motivating problem it's trying to solve) > of the longed-for UXKit that'll supposedly unify all. > > Even if we have these proposed literals, the various Apple-proprietary > frameworks would have to be modified to accept them (to be expressible by > them, in the new parlance). We could equally well appeal for the frameworks > to be modified so that NS* types and UI* types play nicely together, without > providing these pan-Swift facilities. Server code, for instance, could have > little need for a font literal. > > On Mon, Jul 11, 2016 at 00:53 Erica Sadun via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: >> >> I share the concern with others about the usefulness of these, but I also >> like your note about standardizing syntax, and really like that these merge >> together all the different syntaxes for literals we've seen. > > Literals enable you to write cross platform code with a minimum of > redundant and platform-configured code. > > In today's Swift, you can say: let myColor = color literal and that code is > cross-compatible for all Apple platforms, whether UIColor, NSColor, and > SKColor. > If you write that same request as let myColor = UIColor(...), it will no > longer > compile on Cocoa. > > I'm proposing to extend these existing behaviors to create common code > inherently > universal tasks with common structure: NSFont/UIFont, point2/CGPoint/NSPoint, > etc > >> To that end, I'd like to modestly suggest that #literal.foo (as already >> written in the proposal) should be the canonical form of a literal in source >> text, whereas #foo is the one you see used in the code editor. > > I've already filed radars asking that the code editor let you see the raw > unrendered literals > and heartily encourage duped radars to support that end. > >> I'm not a fan of namespacing in #literal, because every literal should >> obviously be a literal; I wouldn't ever recommend numerals fall under this >> proposal as written, for instance. > > The core team has suggested they'd like to use namespacing, especially with > related > items that could otherwise spread and grow in an unmanaged way. > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
