[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Gwendal Roué]

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

+1

> 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 https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#motivation-and-context ?

Gwendal