Re: [swift-evolution] Swift Extensions on Overlay Structs

[Tony Parker via swift-evolution]

> On Nov 13, 2016, at 11:43 PM, Fabian Ehrentraud via swift-evolution 
>  wrote:
> 
> That's an interesting idea without having to write type signatures twice.
> 
> The different nullability of the absoluteURL is strange indeed - what if I do 
> a guaranteed cast from NSURL to URL, and absoluteURL would have been nil in 
> the original object?

Much of the nullability of struct URL changed (for the better) because we 
removed the reason for it possibly being nil in NSURL: file reference URLs.

What happens on bridging is that we resolve the file reference URL to a real 
URL. If this fails, then the struct URL points to a specific invalid URL:

https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/URL.swift#L1129
 


In practice file reference URLs are actually pretty rare. And anyway, if the 
file reference URL was invalid upon bridging it would have been invalid when 
you tried to use it from Swift later anyway.

- Tony

> 
> Eiher way, I'd really like to know if URL extensions could be bridged too 
> without casting in a future Swift version.
> 
>   -- Fabian
> 
> 
>> On 13 Nov 2016, at 03:45, Dennis Lysenko > > wrote:
>> 
>> Hmm... would it be possible to define a protocol like "UnifiedURLType", 
>> define each of the properties you need to work with inside your extension 
>> functions as protocol properties inside the protocol UnifiedURLType {} 
>> declaration, create an extension UnifiedURLType {} and include doSomething() 
>> inside the extension, and then create extensions on both URL and NSURL 
>> causing them to conform to UnifiedURLType? (extension URL: UnifiedURLType 
>> {}; extension NSURL: UnifiedURLType {})
>> 
>> You could try it, but I wouldn't hold my breath, especially if you're 
>> planning on using absoluteURL within your extension as something as basic as 
>> the type of that variable is already different between the two types. 
>> 
>> Dennis
>> 
>> On Fri, Nov 11, 2016 at 3:08 AM Fabian Ehrentraud via swift-evolution 
>> > wrote:
>> Hi list,
>> 
>> Since Swift 3 there exist overlay structs, e.g. NSURL gets bridged to URL.
>> Unfortunately now extensions on URL are not getting bridged back to ObjC:
>> 
>> 
>> extension URL {
>> func doSomething() -> URL {
>> return self.absoluteURL
>> }
>> }
>> 
>> + (NSURL *)swiftStructExtensionCaller {
>> NSURL *url = [NSURL 
>> URLWithString:@"https://apple.github.io/swift-evolution/ 
>> "];
>> return [url doSomething];
>> }
>> 
>> The compiler does not see the method `doSomething`. Is this on purpose, or 
>> something that has yet to be improved?
>> 
>> I'm aware that I could write the extension on NSURL, but that would mean a 
>> lot of casting on the Swift side.
>> 
>> 
>>   -- Fabian
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift Extensions on Overlay Structs

[Fabian Ehrentraud via swift-evolution]

That's an interesting idea without having to write type signatures twice.

The different nullability of the absoluteURL is strange indeed - what if I do a 
guaranteed cast from NSURL to URL, and absoluteURL would have been nil in the 
original object?

Eiher way, I'd really like to know if URL extensions could be bridged too 
without casting in a future Swift version.

  -- Fabian


On 13 Nov 2016, at 03:45, Dennis Lysenko 
> wrote:

Hmm... would it be possible to define a protocol like "UnifiedURLType", define 
each of the properties you need to work with inside your extension functions as 
protocol properties inside the protocol UnifiedURLType {} declaration, create 
an extension UnifiedURLType {} and include doSomething() inside the extension, 
and then create extensions on both URL and NSURL causing them to conform to 
UnifiedURLType? (extension URL: UnifiedURLType {}; extension NSURL: 
UnifiedURLType {})

You could try it, but I wouldn't hold my breath, especially if you're planning 
on using absoluteURL within your extension as something as basic as the type of 
that variable is already different between the two types.

Dennis

On Fri, Nov 11, 2016 at 3:08 AM Fabian Ehrentraud via swift-evolution 
> wrote:
Hi list,

Since Swift 3 there exist overlay structs, e.g. NSURL gets bridged to URL.
Unfortunately now extensions on URL are not getting bridged back to ObjC:


extension URL {
func doSomething() -> URL {
return self.absoluteURL
}
}

+ (NSURL *)swiftStructExtensionCaller {
NSURL *url = [NSURL 
URLWithString:@"https://apple.github.io/swift-evolution/;];
return [url doSomething];
}

The compiler does not see the method `doSomething`. Is this on purpose, or 
something that has yet to be improved?

I'm aware that I could write the extension on NSURL, but that would mean a lot 
of casting on the Swift side.


  -- Fabian
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift Extensions on Overlay Structs

[Dennis Lysenko via swift-evolution]

Hmm... would it be possible to define a protocol like "UnifiedURLType",
define each of the properties you need to work with inside your extension
functions as protocol properties inside the protocol UnifiedURLType {}
declaration, create an extension UnifiedURLType {} and include
doSomething() inside the extension, and then create extensions on both URL
and NSURL causing them to conform to UnifiedURLType? (extension URL:
UnifiedURLType {}; extension NSURL: UnifiedURLType {})

You could try it, but I wouldn't hold my breath, especially if you're
planning on using absoluteURL within your extension as something as basic
as the type of that variable is already different between the two types.

Dennis

On Fri, Nov 11, 2016 at 3:08 AM Fabian Ehrentraud via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi list,
>
> Since Swift 3 there exist overlay structs, e.g. NSURL gets bridged to URL.
> Unfortunately now extensions on URL are not getting bridged back to ObjC:
>
>
> extension URL {
> func doSomething() -> URL {
> return self.absoluteURL
> }
> }
>
> + (NSURL *)swiftStructExtensionCaller {
> NSURL *url = [NSURL URLWithString:@"
> https://apple.github.io/swift-evolution/;];
> return [url doSomething];
> }
>
> The compiler does not see the method `doSomething`. Is this on purpose, or
> something that has yet to be improved?
>
> I'm aware that I could write the extension on NSURL, but that would mean a
> lot of casting on the Swift side.
>
>
>   -- Fabian
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift Extensions on Overlay Structs

[Fabian Ehrentraud via swift-evolution]

Hi list,

Since Swift 3 there exist overlay structs, e.g. NSURL gets bridged to URL.
Unfortunately now extensions on URL are not getting bridged back to ObjC:


extension URL {
func doSomething() -> URL {
return self.absoluteURL
}
}

+ (NSURL *)swiftStructExtensionCaller {
NSURL *url = [NSURL 
URLWithString:@"https://apple.github.io/swift-evolution/;];
return [url doSomething];
}

The compiler does not see the method `doSomething`. Is this on purpose, or 
something that has yet to be improved?

I'm aware that I could write the extension on NSURL, but that would mean a lot 
of casting on the Swift side.


  -- Fabian
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution