>>> 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
