<div dir="ltr"><div style="white-space:pre-wrap">On Thu, Aug 25, 2016 at 17:08 Vladimir.S via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> &gt; The behavior is due to the Objective-C bridge, which I don’t think exists<br>
 &gt; on the Linux version. On the Mac version, fooIsNSString will be true<br>
 &gt; because of the bridging magic that lets you convert between String and<br>
 &gt; NSString (and other equivalent Swift and Objective-C data types) using<br>
 &gt; “as”.<br>
<br>
Well, if I understand correctly, exactly here we are trying to cast<br>
instance *typed* as `Any`, not as `String`. But it seems that this magic<br>
exists in Linux version too, but with little different behavior.<br>
Just made some tests, got interested results:<br>
<br>
Swift Ver. 3.0 (Aug 24, 2016)<br>
Platform: Linux (x86_64)<br>
<br>
import Foundation<br>
<br>
let fooAsNSString = &quot;foo&quot; as NSString<br>
<br>
print(type(of: fooAsNSString)) // NSString<br>
<br>
let foo: Any = &quot;Foo&quot;<br>
let fooAsString = &quot;Foo&quot;<br>
let bar: Any = NSString(string: &quot;Bar&quot;)<br>
<br>
print(type(of: foo)) // String<br>
print(type(of: bar)) // NSString<br>
<br>
print(fooAsString is NSString) // false<br>
print(&quot;foo&quot; is NSString) // true<br>
<br>
print(foo is NSString) // false<br>
print(bar is NSString) // true<br>
<br>
<br>
WARNINGS:<br>
cast from &#39;String&#39; to unrelated type &#39;NSString&#39; always fails<br>
print(fooAsString is NSString)<br>
<br>
&#39;is&#39; test is always true<br>
print(&quot;foo&quot; is NSString)<br>
<br>
<br>
Still, I believe that due to *SE-0072*<br>
1) Linux version work more correctly and Mac&#39;s version should be fixed<br>
2) There is a bug in Linux version, which produces<br>
&quot;foo&quot; is NSString ==  true<br>
<br>
Am I missing something?<br></blockquote><div><br></div><div style="white-space:pre-wrap">There is no bug. Recall that &quot;foo&quot; is a string literal, which means that it has no type of its own. Since NSString conforms to ExpressibleByStringLiteral,&quot;foo&quot; is NSString == true because you are testing if a value that&#39;s inferred to be of type NSString can be cast to NSString. This does not have anything to do with bridging.</div><div style="white-space:pre-wrap"><br></div><div style="white-space:pre-wrap">SE-0072 has to do with _implicit_ bridging from Objective-C to Swift (i.e. NSString to String), and indeed you will find that implicit bridging in that direction has been eliminated on a Mac:</div><div style="white-space:pre-wrap"><br></div><div style="white-space:pre-wrap">```</div><div style="white-space:pre-wrap">import Foundation</div><div style="white-space:pre-wrap">let foo = &quot;abc&quot; as NSString</div><div style="white-space:pre-wrap">let bar: String = foo</div><div style="white-space:pre-wrap">// Error: NSString is not implicitly convertible to String [Fix-it: Insert &quot; as String&quot;]</div><div style="white-space:pre-wrap">```</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(Just got confused.. How should I cast NSString to String in Linux(or any)<br>
version of Swift?</blockquote><div><br></div><div>On Darwin platforms, you perform an explicit conversion by writing `foo as String` (where foo is your NSString instance).</div><div>On Linux, it appears you need to write `foo._bridgeToSwift()` for the moment.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Tried various variants like nsstring as! String and<br>
String(describing: nsstring) - got compilation/runtime error)<br>
<br>
On 26.08.2016 0:31, Charles Srstka wrote:<br>
&gt;&gt; On Aug 25, 2016, at 4:15 PM, Vladimir.S via swift-evolution<br>
&gt;&gt; &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>&gt;&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; let fooIsNSString = foo is NSString           // true<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t understand. Why is so? On which version of Swift did you try this?<br>
&gt;&gt;<br>
&gt;&gt; IBM Swift Sandbox<br>
&gt;&gt; Swift Ver. 3.0 (Aug 23, 2016)<br>
&gt;&gt; Platform: Linux (x86_64)<br>
&gt;&gt;<br>
&gt;&gt; import Foundation<br>
&gt;&gt;<br>
&gt;&gt; let foo: Any = &quot;Foo&quot;<br>
&gt;&gt; let bar: Any = NSString(string: &quot;Bar&quot;)<br>
&gt;&gt;<br>
&gt;&gt; let fooIsString = foo is String<br>
&gt;&gt; print(fooIsString) // true<br>
&gt;&gt;<br>
&gt;&gt; let fooIsNSString = foo is NSString<br>
&gt;&gt; print(fooIsNSString) // false! as expected<br>
&gt;<br>
&gt; The behavior is due to the Objective-C bridge, which I don’t think exists<br>
&gt; on the Linux version. On the Mac version, fooIsNSString will be true<br>
&gt; because of the bridging magic that lets you convert between String and<br>
&gt; NSString (and other equivalent Swift and Objective-C data types) using<br>
&gt; “as”. Never mind that “foo as NSString” isn’t even fewer characters than<br>
&gt; “NSString(foo)”; somebody decided it was easier that way. And of course,<br>
&gt; “is”, “as?” and the rest of the family have to behave the same way for<br>
&gt; consistency. As a result, you can never be 100% sure what’s actually going<br>
&gt; to happen when you use “as?”, which is one of the reasons I dislike “as?”.<br>
&gt; SE-0083 attempted to remove this bridging magic from the dynamic casts and<br>
&gt; make them only truthfully report the type of the object or struct you were<br>
&gt; looking at, but it was deferred until “later in Swift 3”, and Swift 3 has<br>
&gt; progressed past the point where source-breaking changes are accepted, so<br>
&gt; that proposal is probably dead at this point.<br>
&gt;<br>
&gt; The source incompatibility that this bridging behavior can create between<br>
&gt; Swift on the Mac and on other platforms is actually a pretty good point in<br>
&gt; favor of SE-0083 that I wish we’d thought of before everything became<br>
&gt; locked down.<br>
&gt;<br>
&gt; Charles<br>
&gt;<br>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</blockquote></div></div>