No 1. which is missing everywhere: Everything should return a value, there shouldn't be any statements.
Pitched. Rejected.
Swift: Things I really wanted that won’t make it
31–40 of 54 posts
Re: Swift: Things I really wanted that won’t make it
#32No 1. which is missing everywhere: Everything should return a value, there shouldn't be any statements.
why? don't you need side effects, like print("hello world")
Re: Swift: Things I really wanted that won’t make it
#33Earlier quoted context omitted.
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!`.
If the type signature was: func throwing() throws FooError -> Int or even: func throwing() throws (FooError, BarError) -> Int to create an implicit sum type, I'd find it acceptable, but not being able to tell what types of errors an API will throw is far from ergonomic - you'll need a catch-all block if you use anything but NSError[1] or ErrorType, even if you know the function only throws FooErrors. [1] this is espe…
One reason to avoid explicit lists of "error types" (exceptions) for methods is that method parameters are usually covariant whereas you really want exceptions to be contravariant[1]. This has big implications for higher-order functions and it's why everybody rightly hates explicit "throws" clauses in Java.
[1] Or to put it in more practical terms: Imagine two classes/interfaces A and B where B subclasses A. Any method on B that overrides a method on A is free to accept a "more restricted" parameter than the method on A, but since it (presumably) does something more specialized it must also be able to throw more exceptions that A's method was. (Maybe it's accessing files and needs to be able to throw FileIOError, or whatever.)
Re: Swift: Things I really wanted that won’t make it
#34Re: Swift: Things I really wanted that won’t make it
#35Earlier quoted context omitted.
If the type signature was: func throwing() throws FooError -> Int or even: func throwing() throws (FooError, BarError) -> Int to create an implicit sum type, I'd find it acceptable, but not being able to tell what types of errors an API will throw is far from ergonomic - you'll need a catch-all block if you use anything but NSError[1] or ErrorType, even if you know the function only throws FooErrors. [1] this is espe…
One reason to avoid explicit lists of "error types" (exceptions) for methods is that method parameters are usually covariant whereas you really want exceptions to be contravariant[1]. This has big implications for higher-order functions and it's why everybody rightly hates explicit "throws" clauses in Java. [1] Or to put it in more practical terms: Imagine two classes/interfaces A and B where B subclasses A. Any meth…
Idiomatic Swift shouldn't really be using inheritance though, protocols (which support associatedtype, making varying errors types not an issue) are generally preferred.
Functions would be free to just "throws ErrorType" (probably the default for blank "throws", to avoid breaking backwards compatibility) if they really wanted to though, just like they can accept and return "Any", and the behavior would be identical to today.
I prefer Result though, which just solves the problem of disjoint error types by using "mapError" and a sum type.
Re: Swift: Things I really wanted that won’t make it
#36Re: Swift: Things I really wanted that won’t make it
#37Swift is not perfect but I've been writing it a bunch recently and it's hands down one of the most productive languages I've written in. Fundamentally I believe that it might be one of the most important languages because it's relatively close to the metal, it's a 'modern language' (i.e. functional, has a pretty good type system), open source, and a major company and platform behind it. I think that if Swift 4.0 adds…
We will also need a dashboard like Akka for profiling concurrency will be a bonus.
Re: Swift: Things I really wanted that won’t make it
#38Sorry 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…
Agreed. I don't even like the fact that you can turn off subclassing, that's very un-object-oriented IMHO.
I don't have any experience with Swift, but how to you approach unit testing with everything `final`? Being able to inject mock subclasses is a staple of OO testing.
Re: Swift: Things I really wanted that won’t make it
#39Dart's method cascade syntax is still the best I've seen, that's immediately intuitive and unambiguous:
let task = NSTask()
..launchPath = "/usr/bin/mdfind"
..standardOutput = pipe
..launch()
..waitUntilExit()Re: Swift: Things I really wanted that won’t make it
#40Earlier quoted context omitted.
Agreed. I don't even like the fact that you can turn off subclassing, that's very un-object-oriented IMHO.
I don't have any experience with Swift, but how to you approach unit testing with everything `final`? Being able to inject mock subclasses is a staple of OO testing.
I don't know Swift, but I know I testing... your constructors should be accepting interfaces (for things that are complex enough that you'd want to mock them), not concrete types. In Swift I gather you'd use protocols.