You're saying that there is universally no inherent difference, and that all calls "determine if you have called it" correctly, but then picked one of only a handful of cases in current practice where that is actually true. Yes "+" (/other math operators) and array access are unsafe, but most other things in Swift are safe by default, and you have to opt into un-safety (e.g. forcing or checking an optional or throwing call) — this is a main tenant of the language.
Perhaps I was not totally clear while mixing and matching my observations/interpretations of safety and fallibility in compile vs. runtime and readability vs. writability in my initial email, but I believe the spirit of my concern was clear: there is obviously a difference between dynamic and static languages/calls, and having the syntax the same is misleading in a language centered around static safety, perhaps to a degree where it is ergonomically counter productive. On Mon, Nov 27, 2017 at 4:12 PM, Magnus Ahltorp <m...@kth.se> wrote: > > 27 Nov. 2017 22:38 Mathew Huusko V via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I tuned out the initial discussions of this proposal because there > seemed to be a lot of noise centered around implementation/maintainability. > I'm curious if the actual premise of the syntactic/sugar conversion has > been discussed/debated yet? i.e. making dynamic/stringly calls look like > normal calls is very clean, but it's also very misleading (by definition; > they're not normal/safe/checked calls) with a potential net reduction in > ergonomics. > > There is nothing that is inherently non-fallible with "normal" Swift > calls. As far as the caller can tell, any function or method you call can > fail. There is no difference here; the implementation of the "user-defined > dynamic member lookup" object will determine if you have called it in a > proper way or not, in the same way as "+" will determine if you have called > it in a way that overflows or not. > > /Magnus > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
