I agree. Instead of a magic protocol, think I'd rather see "@dynamic" used like "@objc" is today. Maybe only applicable to class declarations.
Implicitly unwrapped sounds reasonable... need to think on that some more. -- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf * http://agilesolutionspace.blogspot.com/ > On Dec 9, 2017, at 9:20 AM, Steven Brunwasser via swift-evolution > <swift-evolution@swift.org> wrote: > > Just wanted to give my 2¢ > > ¢ > I don’t like empty protocols—they feel like an abuse of the feature. I think > attributes are the right way to go, since this proposal is about enabling > syntactic sugar for types which can’t yet be described in the language as-is. > This prevents retroactive conformance on preexisting types, which some have > raised as a concern. > > ¢ > I think the discussion about whether or not implementations should throw, > return optional, or be implicitly unwrapped is a larger discussion on its > own, and should probably be a separate proposal to steer the language towards > a more well defined convention. That being said, I’m of the opinion that they > should always return an implicitly unwrapped value. The precedent is already > in the language, it allows for cleaner syntax while also explicitly stating > “hey, just so you know, I might not work, so be careful, ok?”, and callers > can choose to be more cautious by explicitly using the ? operator. > > That is all, > - Steve > >> On Dec 8, 2017, at 16:34, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> See below. >>> >>>> On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> Apologies, I may have misunderstood you. What I wanted to say is that I >>>> see no problem allowing "dangerous" stuff that may be abused. >>> >>> You see no problem with danger and abuse? >>> >>> I guess we have differing philosophies... >>> >>> https://developer.apple.com/swift/ states: >>> >>> “Swift eliminates entire classes of unsafe code.” >>> >>> Lets keep it that way. >>> >>> I’m all for this proposal if it can be tweaked to where any of the >>> dangerous invocations contain the word, “Unsafe”, or equivalent. >> >> Again, in Swift, “safety” means something very specific. Trapping at runtime >> is safe; in fact, trapping at runtime is *precisely the means by which >> safety is achieved* in the case of integer overflow and array indexing. This >> proposal introduces nothing that is unsafe. >> >>> ~Jon >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
