> On Jan 16, 2017, at 12:48 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Jan 16, 2017, at 09:08 , Charles Srstka <cocoa...@charlessoft.com > <mailto:cocoa...@charlessoft.com>> wrote: >> >> The thing with file reference URLs degrading to file path URLs is in the >> Swift is actually not a bug, it’s deliberate >> (https://bugs.swift.org/browse/SR-2728 >> <https://bugs.swift.org/browse/SR-2728>). The Swift team decided that file >> reference URLs are not appropriate for the Swift URL value type. > > Does the given justification make any sense to you? It certainly makes no > sense to me. Perhaps I’m missing something, but the discussion seems to me to > conflate the idea of a reference type in Swift with the concept of > “referencing” in the world in general: > >> “The[y] are both technically a different type in spirit[**] and they >> actually behave much more like a reference type than a structure.” > > > By analogy, this is like saying that the Swift String type is good for > representing people’s names, but that Obj-C NSString should be used for > representing [US] people’s social security numbers, because a SSN is more > like a reference than a value. > > In fact, URLs *are* strings — URLs as defined by the RFC, I mean — and that > takes the semantics of relating the string to the resource that the string > locates outside the scope of the representation itself. > > Perhaps the problem is that file reference URLs don’t have an eternal, unique > string representation — that storing and reconstituting a file reference URL > may produce a different string? In that case, it’s the URL (the value, not > the type) that’s broken, and it’s just as broken in Obj-C as Swift. > > > ** Incidentally, they aren’t a different *type* in spirit. File URLs and file > reference URLs are both URLs: uniform [syntactically conformant with the RFC] > resource [file, in this case] locators [specifiers of where to find]. The > difference is in the semantics of the file system, which really has nothing > to do with the syntax of the URL.
This post from Apple clarified their reasoning a bit: https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20161205/001052.html <https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20161205/001052.html> Basically, they wanted to get rid of the optionality on many of URL’s properties; in Swift 2, .path was optional, .lastPathComponent was optional, and possibly some others as well. Apparently the only times those methods ever returned nil was when the URL in question was a file reference URL; in Swift 3, those methods are no longer optional, but file reference URLs are no longer supported. :-/ The part of the message that I find ominous is where he says “If references were still important”. When you start hearing language like that from Apple, it’s usually a sign that they consider the feature no longer relevant and soon to be axed. File references were always a key differentiator in the Mac user experience, and it would be very sad to see them go. Charles _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
