11–20 of 54 posts
Error and Result types in the standard library, macros, per-target configurations and tests, a fix for namespacing issues due to the lack of a central repository for open-source libraries. The presence/lack of each of these are some of my favorite things about Rust, and it's too bad to see them miss this release of Swift.
Sorry but final by default is not a good idea IMO. All my work is client work. There have been a bunch of occasions where I've had to work around some weirdness of an Apple SDK by creating my own subclass. I could see Apple releasing an SDK and many of the classes being @final. Then I'm stuck in a situation where I can't provide a deliverable to the specifications a client wants due to a limitation in an SDK. That's…
final by default doesn't prevent someone from manually adding final to their classes.
> Disambiguating SPM Naming Conflicts Perl 6 did some work on this. I'm not sure if it's fully supported yet, but the design docs[1] go into detail on how it's supposed to work, so it may be worth looking at. > Method Cascades I suspect you might find disambiguating your method/attribute access easier in your "with" syntax if you make it match what swift appears to do for anonymous variables, use $0. (pardon my unfam…
func with(value: T, f: T -> Void) -> T {
f(value)
return value
}
let task = with(NSTask()) {
$0.launchPath = "/usr/bin/mdfind"
$0.arguments = ["kMDItemDisplayName == *.playground"]
$0.standardOutput = pipe
$0.launch()
$0.waitUntilExit()
}
Sorry but final by default is not a good idea IMO. All my work is client work. There have been a bunch of occasions where I've had to work around some weirdness of an Apple SDK by creating my own subclass. I could see Apple releasing an SDK and many of the classes being @final. Then I'm stuck in a situation where I can't provide a deliverable to the specifications a client wants due to a limitation in an SDK. That's…
It would be nice to have an "evil_override" keyword (or some other such name). There's no fundamental technical reason you can't do it, with unsafe pointer black magic if necessary, and it's sort of like an LD_PRELOAD: it's not a good solution, but sometimes you have to break abstraction barriers to get things done, and at least if you're using it you're explicitly saying you're breaking abstraction barriers. final b…
Error and Result types in the standard library, macros, per-target configurations and tests, a fix for namespacing issues due to the lack of a central repository for open-source libraries. The presence/lack of each of these are some of my favorite things about Rust, and it's too bad to see them miss this release of Swift.
Swift's error handling model essentially tosses type information out the window. I really don't understand why it was created instead of a first-party Result type.
Smalltalk-like. Go back one more step and the influence almost certainly comes from there. (Drink!)
Earlier quoted context omitted.
Agreed. I don't even like the fact that you can turn off subclassing, that's very un-object-oriented IMHO.
Idiomatic Swift is primarily protocol-based, object-orientation is mostly used when talking to the Cocoa frameworks, which aren't idiomatic Swift code. But the main problem with subclassing is: https://en.wikipedia.org/wiki/Fragile_base_class
This is how it should work in many production environments: Are you 100% sure about that? No? Don't do that! Then start asking why you can't be sure, then fix that. Rinse, repeat.
Method Cascades. Dart-like for the win. Smalltalk-like. Go back one more step and the influence almost certainly comes from there. (Drink!)
> Disambiguating SPM Naming Conflicts Perl 6 did some work on this. I'm not sure if it's fully supported yet, but the design docs[1] go into detail on how it's supposed to work, so it may be worth looking at. > Method Cascades I suspect you might find disambiguating your method/attribute access easier in your "with" syntax if you make it match what swift appears to do for anonymous variables, use $0. (pardon my unfam…
You can nearly implement your version of `with` today: func with (value: T, f: T -> Void) -> T { f(value) return value } Which you could then use like: let task = with(NSTask()) { $0.launchPath = "/usr/bin/mdfind" $0.arguments = ["kMDItemDisplayName == *.playground"] $0.standardOutput = pipe $0.launch() $0.waitUntilExit() } The `let task =` part would be optional, and you could leave it off if you don't need to use t…
Your solution is actually simple enough that I'm not sure there needs to be a change to the language, unless there's some special behavior they can and should impart that we aren't thinking if.
That said, I don't write swift, so feel free to take my opinion for whatever you think it's worth. :)
Earlier quoted context omitted.
Swift's error handling model essentially tosses type information out the window. I really don't understand why it was created instead of a first-party Result type.
First-class error handling is a little more ergonomic than just having a `Result` type that is used by convention, so I can see why Swift went that route if they were looking to improve ergonomics a bit. Rust has been gradually working on making its own `Result` type a bit more first-class, first with the `try!` macro, and in the future with the `?` operator which will improve upon `try!`.
func throwing() throws FooError -> Int
func throwing() throws (FooError, BarError) -> Int
[1] this is especially weird because NSError is just some random Foundation class, it's not anything inherent to the Swift language.