> On Dec 6, 2017, at 9:45 PM, Paul Cantrell <cantr...@pobox.com> wrote:
>
> This seems marginally tolerable, but excessive.
>
> Do we mark every usage of a type that can generate precondition failures or
> fatal errors for reasons other than “no such method?” No, we don’t.
>
> Do we use a syntactically privileged marker instead of just using words like
> “unsafe” for types that expose direct access to raw memory? No, we don’t.
>
> Has all of this ruined the language thus far? No. Because the Swift core team
> doesn’t design, and the Swift community doesn’t adopt, ill-designed APIs that
> turn these facts into problems.
Yeah, I think I'd prefer this to stay as a normal protocol conformance. But if
the proportion of resistance is high enough, I think the adoption of some
annotation above and beyond the norm would be ok (again, at the declaration
site, not the call site). Especially since this is a somewhat privileged
protocol if any of the restrictions suggested in the proposal go forward, since
they don't really apply to normal protocols.
> My main objection to the critical responses is that most of the objections
> are fundamentally cultural, not technical, and are fear-based, not
> evidence-based.
>
> If a little extra language ceremony helps assuage those fears, I guess I’d
> consider it. I still think static analysis — starting and mostly ending with
> boring old syntax coloring — answers most all the concerns people have
> raised, and this debate is a tempest in a teapot.
I agree wholeheartedly. I was just trying to bring some specifics to the
examples given so far.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
