Late, I know, but since it’s a simple search-and-replace change, I wonder if the team might consider renaming URL(fileURLWithPath:), which is quite verbose, to URL(filePath:), which conveys the same information while being much less painful to type.
Charles
There are many, many of these and it would be great to find out how to request them. I suspect the window of opportunity has passed for code-breaking changes though.
-- E
On Aug 5, 2016, at 4:29 PM, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:
Late, I know, but since it’s a simple search-and-replace change, I wonder if the team might consider renaming URL(fileURLWithPath:), which is quite verbose, to URL(filePath:), which conveys the same information while being much less painful to type.
Charles
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I do, too, but I figured it doesn’t hurt to try. If there is some small chance that this can still be changed, it would save us all a nasty case of carpal-tunnel syndrome from typing this unnecessary construction all the way from now to eternity. “fileURLWithPath:” is extremely verbose and redundant for something that is used so often, and it's the one thing that I’ve always hated about the URL-based file APIs. I’m kicking myself for not thinking to request this earlier, but better late than never, I suppose.
Charles
On Aug 5, 2016, at 7:32 PM, Erica Sadun <erica@ericasadun.com> wrote:
There are many, many of these and it would be great to find out how to request them. I suspect the window of opportunity has passed for code-breaking changes though.
There are many, many of these and it would be great to find out how to request them. I suspect the window of opportunity has passed for code-breaking changes though.
Right. We’ll have some limited ability to do source breaking changes in Swift 4, but we need to figure out how the mitigation strategy will work (in full detail) so we know exactly what sort of changes will work.
-Chris
On Aug 5, 2016, at 5:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
-- E
On Aug 5, 2016, at 4:29 PM, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:
Late, I know, but since it’s a simple search-and-replace change, I wonder if the team might consider renaming URL(fileURLWithPath:), which is quite verbose, to URL(filePath:), which conveys the same information while being much less painful to type.
Charles
_______________________________________________
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
Right. We’ll have some limited ability to do source breaking changes in Swift 4, but we need to figure out how the mitigation strategy will work (in full detail) so we know exactly what sort of changes will work.
What about having additional source-breaking changes (like the one pitched here) in Swift 3.x versions?
I'd prefer to still allow the old signature, and raise either a deprecation warning, or introduce a new warning type. This would ensure you don't have to make all the changes the minute a new version of Swift/Xcode is released, without having to stick to an older version of the language itself. It's just the name after all.
Having a separate warning type for these would allow to easily hide (or disable) them while working on a more urgent issue first, or to hide these purely cosmetic warnings in CI builds.
It wouldn't have to be limited to the Swift 4 timeframe either but could provide a smooth transition whenever needed, similar to how it's done with the SDK updates, too.
On 07.08.2016, at 10:00, Georgios Moschovitis via swift-evolution <swift-evolution@swift.org> wrote:
Right. We’ll have some limited ability to do source breaking changes in Swift 4, but we need to figure out how the mitigation strategy will work (in full detail) so we know exactly what sort of changes will work.
What about having additional source-breaking changes (like the one pitched here) in Swift 3.x versions?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution