> 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.
fatalError shouldn’t be used excessively. API surface areas for these types are 
going to be massive (infinite technically). I assume many people are going to 
be writing a lot of code would these types and calling many methods and 
properties which would all essentially have a fatalError. Would you consider it 
good code if the majority of all your types had methods defined with fatalError 
calls. What’s so wrong with adding another layer of protection on top to bypass 
if you want to do this.

> 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.
Okay we use Unsafe. Then should we have something similar for this. A 
UncheckedDynamicMemberLookup [1] and a DynamicMemberLookup [2]? my one 
objection to this would be that I would like to convert a 
UncheckedDynamicMemberLookup to a DynamicMemberLookup.

[1] would work like the current proposal for DynamicMemberLookup
[2] would only allow returning an optional

> 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.

The goal of this proposal is to bring people from a culture where excessive use 
of this would be the norm for them. Why would it be so hard to imagine that 
people would adopt bad principles, knowing or unknowing, because this is what 
they’ve always done?

Evidence is going to be hard to get since I don’t know any other language like 
Swift that has done this for the same reasons before. As far as C# goes were 
they trying to get people from a heavily based dynamic community or help those 
already in the community?

> 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'm unsure of this, but as far as I’m aware Swift language proposals shouldn’t 
rely on editor features. But like I said I’m unsure of this and if someone 
could clarify this that would great.

swift-evolution mailing list

Reply via email to