<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 5, 2017 at 12:48 PM, Benjamin G via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_5917569653452401360gmail-"><div><br></div></span><div>For what i&#39;m concerned, let&#39;s be very clear : i do not consider my personal opinion to matter AT ALL compared to what people like you, who code compilers for a living, think. And i feel even more embarrassed participating in that conversation since it&#39;s about a language you invented. I&#39;ve only done it because people in the core team said it would be interesting.<br></div><div>Now, the only area where I may have more experience than people like you, is working with the average programmer, in the industry. And my personal experience shows that what a language doesn&#39;t enable is as important as what it enables (because every feature that can be abused will be, eventually and in ways nobody can expects).</div><div><br></div>Regarding your proposal regarding the impact it could have on pure swift, i think it comes down to letting the developer masquerade dictionaries into proper structs or classes. I tried to recreate a dynamic BaseDynamicObject based on dictionaries and your new protocols, but it&#39;s pretty hard without the finished implementation (i will try to recompile swift using your pull request wheneve i got the time, if i feel people are sincerely interested). <br></div><div class="gmail_quote">The &quot;benevolent&quot; purpose for doing that would be anything regarding mocking, proxying, mixins objects and their properties. There are various examples of those patterns in every dynamic languages. <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">About C#, in which i did program a few years ago (but before dynamic was in the language), it already had powerful metaprogramming and introspection capabilities, as well as very convenient  generics and interfaces ( easier to work with than what swift offers today, but that was a long time ago so my memory may be wrong). So, in some way, the potential for abusing dynamic or &quot;stringly typed&quot; programming was a lot lower. </div></div></div></blockquote><div><br></div><div>This is in essence what my concerns boil down to as well (as described in my initial response to this thread).</div><div><br></div><div>If Swift had a rock-solid Generics system at this point and plenty of support for Meta-Programming via hygienic example-based or procedural macros and/or compiler plugins, then I&#39;d be way less concerned about this feature getting misused.</div><div><br></div><div>Alas while Swift&#39;s generics provide a nice basic foundation, they still have big gaps in what can be expressed through them.</div><div>And i&#39;m not talking about HKT or any such more advanced use of types). I&#39;m talking about the basic stuff. Generic abstractions over type conversion. Generic abstractions over arithmetic operators. This kind of stuff. Stuff, that ironically would be necessary for a generic yet idiomatic implementation of Linear Algebra algorithms in Swift.</div><div><br></div><div>I would prefer to get these gaps filled up before providing an orthogonal feature that can easily be misinterpreted as a solution to the deficits in Swift&#39;s generics system by someone coming from a dynamic language and/or doesn&#39;t fully understand the use of generics.</div><div><br></div><div>We&#39;d in essence be providing what looks like a solution in a time where thousands of people are looking for workarounds to the limited expressiveness of Swift&#39;s type system. That&#39;s like handing out bottles of Methanol for its use as a household item in a time of severe drought. What could possibly go wrong?</div><div><br></div><div>It&#39;s also a completely different situation than what (from my understanding) C# was in when they added `dynamic`.</div><div><br></div><div>---</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Further, adding something like .dynamic would completely undermind the proposal.  You can already write:<br><span style="white-space:pre">        </span>x.get(“foo”).get(“bar”)<br>having to write:<br><span style="white-space:pre">        </span>x.dynamic.foo.dynamic.bar<br>has no point.</blockquote><div><br></div><div>By the law of demeter you shouldn&#39;t be accessing `.foo.bar` on `x` in the first place. This is optimizing for bad use.</div></div><div>I would instead consider this a form of syntactic salt. Intentionally pushing people to refine their APIs.</div><div><br></div><div>As such you should only ever have a single `.dynamic` per object in a scope:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>x.dynamic { x in</div></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>    x.foo</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>    x.fooBar</div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>}</div></div></div></blockquote><br><div class="gmail_extra"><div class="gmail_quote"><div>---</div><div><br></div><div>On a technical level I think that this is a well thought-out proposal.</div><div>And I wouldn&#39;t expect any less from you, Chris.</div><div><br></div><div>But I think that it&#39;s too early for it. The language simply isn&#39;t ready for it.</div><div>And I think that we have more urgent topics at hand that need to get fixed.</div><div>Swift&#39;s generics are very limited. We hardly have any tooling.</div><div>Diagnostics are just shy of migrating from &quot;utter garbage&quot; to &quot;getting usable&quot;, by modern standards.</div><div>Integration with Xcode still to this day is an utter clusterfuck. With errors pointing to the void, regularly.</div><div>I&#39;d prefer the team to focus on these, solidifying the foundation and once that&#39;s done</div><div>and the result have been proven to be sound by time I&#39;d love to see Swift get some more dynamism.</div><div><br></div><div>At this point in time it&#39;s like opening Pandora&#39;s box. Regardless of how small and clean the implementation is.<br></div><div>I can understand that you prefer to focus on the technical discussion (with Doug e.g.), but there is always a</div><div>non-technical side to the addition of a major and potentially disruptive feature.</div><div>And the proposal as it is right now pretty much avoids addressing it entirely.</div><div><br></div><div>Your section &quot;Reducing Potential Abuse&quot; only talks about technical abuse mitigation.</div><div>For me the technical challenges are secondary. It&#39;s creating a culture problem from my point of view.</div><div><br></div><div>- How do you plan to teach the proper use of this feature? How would the documentation introduce it</div><div>and how would it ensure that people fully understand its purpose and what it decidedly is _not_ for?</div><div>- How would the diagnostics (in particular in code mixing static and dynamic Swift) look like?</div><div>- How would the debugging of dynamic APIs look like?</div><div>- …</div><div><br></div><div>Could you shine some light on where you see this going in the context of educating about this feature?</div></div></div></div>