[swift-corelibs-dev] Why URL doesn't have fileReferenceURL and isFileReferenceURL, but NSURL has?

[Tony Parker]

You can actually see how we changed our minds on this if you look at the history of the URL.swift file in the Foundation overlay in the Swift project.

Basically: if struct URL could be a reference, then almost all of its methods/functions needed to be marked as ‘throws’, including all of the path manipulation stuff, because all of them touch the file system and touching the file system has the possibility of introducing all kinds of errors. This made the API very cumbersome. In order to dramatically simplify the API, we decided that struct URL should not hold references. If references were still important, they should just be another type. For now, that other type is NSURL.

- Tony

> On Dec 6, 2016, at 4:06 AM, Ilya Laryionau via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> Ole,
> 
> Thank you for a quick response.
> 
> Ilya
> 
>> On 6 Dec 2016, at 14:56, Ole Begemann <ole at oleb.net> wrote:
>> 
>>> The question is the subject, but anyway I’ll repeat it here: Why URL
>>> doesn't have fileReferenceURL and isFileReferenceURL, but NSURL has? Is
>>> it by design? If it’s a bug I can create an issue in https://bugs.swift.org.
>> 
>> It seems this is intentional, see SR-2728: https://bugs.swift.org/browse/SR-2728.
>> 
>> Tony Parker wrote in a comment there:
>> 
>> "Note that it is expected behavior that `struct URL` does not support file reference URLs.
>> 
>> The unfortunate part here is that we don't have a mechanism to keep `NSURL.fileReferenceURL` from being imported as returning `struct URL` instead of `NSURL`. We probably need to add an ObjC thunk in the overlay and mark the API as `NS_REFINED_FOR_SWIFT` in the NSURL.h header. However, that would be a source breaking change."
> 
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev