>>> I’m talking specifically about fatalError not precondition. fatalError is 
>>> something that goes out with production code while precondition is used for 
>>> debugging. I think you would agree a shipped program that has many states 
>>> of being unrecoverable is not a good design?
>> When a question is framed so that there is only one possible answer, the 
>> question is flawed.
>> The question is not whether one likes dynamism or not (the answer is pretty 
>> obvious for many people here, and we don't learn much).
> One might call that a rhetorical question :) Which is probably not 
> appropriate here so I apologies for that.

It's difficult to avoid sometimes ;-)

>> It isn't if one would use the discussed features if the proposals were 
>> accepted (many here would swear they wouldn't, even if many of them will 
>> lick those dynamic features like candy, whenever appropriate, as every sane 
>> person would).
> I’m not sure anyone here ever said they wouldn’t use it. There’s just a 
> concern about how much it would be used.

Yes. And we all share this concern. Or, to put it better, I think : many Swift 
users are sold to the static safety of Swift.

Long gone are the early days when early Swift users were missing ObjC dynamism.

I may live in an echo chamber, but most Swift news I read are about strongly 
typed patterns, and the immense progress in the implementation of the Generics 
Manisfesto, which will bring even more type-safe goodness!

I thus see no threat in Chris's proposal. He even slightly obfuscates the 
identifiers so that no one jumps in by mistake.

>> Currently, it's a static vs. dynamic debate. But we should talk about a 
>> precise proposal, and a good one after that, which comes with plenty of 
>> information, and even playgrounds to look at!
> I’m not taking sides on which is better (each to their own use cases). I am 
> talking about the proposals current design.


> The current design says that dynamic and static calls are on equal footing. 
> This implies to the programmer that either way of doing things is correct. A 
> programmer from a dynamic environment is usually going to choose the dynamic 
> way because it’s more powerful and easier to use. I just merely want the 
> design to have a way of showing the programmer that they should think twice 
> about using it in an implicitly failing way. Whether that be renaming the 
> protocol to something like UnsafeDynamicMemberLookup or something else along 
> the lines of what Swift currently does.

I though the current design was all about easing the use of good libraries that 
are currently only available in dynamic languages.

Do you aim at a particular paragraph in 


swift-evolution mailing list

Reply via email to