<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">As far as I know, dynamicType is something that doesn&#39;t work until the app is running the specific code, which means your codes are no longer protected by the compiler. That is what swift tries to keep you from. So I believe this should not happen in swift at any time. You should use dynamicType as little as possible. You should try generics instead of dynamic type.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">As you said, you&#39;d better to cast it to a protocol instead of dynamicType.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">zhaoxin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 9, 2016 at 12:55 PM, Félix Cloutier <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><div></div><blockquote type="cite"><div>func magic(_ variable: Any) {</div><div><span style="white-space:pre-wrap">        </span>let foo = variable as dynamicType</div><div><span style="white-space:pre-wrap">        </span>// ???</div><div>}</div><div><br></div><div>magic(&quot;hello&quot;)</div><div>magic(42)</div></blockquote><div><br></div>What would be the result of this? What benefit do I get from casting it to its dynamic type?<br><div>
<br><span style="color:rgb(0,0,0);font-family:&#39;Lucida Grande&#39;;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline!important;float:none">Félix</span>
</div>

<br><div><blockquote type="cite"><div><div class="h5"><div>Le 8 janv. 2016 à 23:40:46, Michael Henson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; a écrit :</div><br></div></div><div><div><div class="h5"><div dir="ltr">Currently, the language syntax only allows type identifiers in the type-casting-operator productions:<div><br></div><div>&quot; &quot; surrounds a keyword</div><div><br></div><div>type-casting-operator -&gt; &quot;is&quot; type</div><div>type-casting-operator -&gt; &quot;as&quot; type</div><div><div>type-casting-operator -&gt; &quot;as&quot; &quot;?&quot; type</div></div><div><div>type-casting-operator -&gt; &quot;as&quot; &quot;!&quot; type</div></div><div><br></div><div>The type production doesn&#39;t allow for expressions which resolve to a type, only explicit type references.</div><div><br></div><div>So, if you want to refer to the item *as* its dynamic type, there&#39;s no direct way to do that unless you declare the name of the type in code:</div><div><br></div><div>class Example {}</div><div>var value: Any = Example()</div><div>var again = value as value.dynamicType</div><div>// doesn&#39;t work because value.dynamicType is an expression</div><div><br></div><div>It should be possible to upcast to dynamicType immediately with no chance of failure. To that end, I suggest adding two productions:</div><div><br></div><div>type-casting-operator -&gt; &quot;is&quot; &quot;dynamicType&quot;</div><div>type-casting-operator -&gt; &quot;as&quot; &quot;dynamicType&quot;</div><div><br></div><div>Following along the example above, we could then do:</div><div><br></div><div>var nowPossible = value as dynamicType</div><div><br></div><div>and have nowPossible be Example.Type.</div><div><br></div><div>Possible use cases for this functionality include:</div><div><br></div><div>1. Dealing with mixed-type collections from Objective-C code:</div><div>   @[ @&quot;key1&quot;, @5, @&quot;key2&quot;, @20, @&quot;key3&quot;, @[@&quot;red&quot;,@&quot;green&quot;,@&quot;blue&quot;]]</div><div><br></div><div>2. Taking advantage of type-specific polymorphism without having to modify code:</div><div><br></div><div>    func handleObject(obj: NSNumber) { print(&quot;Number&quot;) }</div><div>    func handleObject(obj: NSData) { print(&quot;Data&quot;) }</div><div><br></div><div>    func dispatchToHandler(kind: AnyObject) {</div><div>        print(&quot;dispatching \(kind.dynamicType)&quot;)</div><div>        handleObject(kind as dynamicType)</div><div>    }</div><div><br></div><div>I suspect that handling this use case might pose the most difficulties when implementing the feature. It might make the whole thing impossible if there&#39;s no way to resolve types at run-time in compiled code. For example, if the dispatcher is in a Framework distributed as a binary and the user does</div><div><br></div><div>class MyClass {}</div><div>func handleObject(obj: MyClass) { print &quot;Success!&quot; }</div><div><br></div><div>let stuff = MyClass()</div><div>dispatchToHandler(stuff)</div><div><br></div><div>in the project&#39;s code, what would happen?</div><div><br></div><div>Casting to an intermediate type between the static and dynamic types would fall out naturally, though in that case you&#39;d already have to know the dynamicType and write the explicit intermediate type name in the code. If that much is known then it&#39;s possible to cast directly to that intermediate type with existing syntax.</div><div><br></div><div>Also, it&#39;s worth noting that the &quot;Any&quot; case is only the broadest instance possible. Anything that passes data along as a super type, by using a Protocol as a concrete type specifier, etc. could benefit from this mechanism.</div><div><br></div><div>Mike</div></div>
</div></div><img alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div>
<img alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><br>Owen Zhao<br></div></div></div>
</div>