Hello Community,
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 <https://bugs.swift.org/>\.
Ilya
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."
Ole,
Thank you for a quick response.
Ilya
On 6 Dec 2016, at 14:56, Ole Begemann <ole@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."
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@swift.org> wrote:
Ole,
Thank you for a quick response.
Ilya
On 6 Dec 2016, at 14:56, Ole Begemann <ole@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev