On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser <[email protected]> wrote:
> Just wanted to give my 2¢ > > ¢ > I don’t like empty protocols—they feel like an abuse of the feature. > As has been discussed here before, protocols aren’t about bags of syntax but rather about semantics. Empty protocols are explicitly a demonstration of this settled principle and are very much consistent with the direction of Swift. 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 < > [email protected]> wrote: > > On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution < > [email protected]> wrote: > >> See below. >> >> On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution < >> [email protected]> 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 >> [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
