Live data from Hacker News

Swift: Things I really wanted that won’t make it

ericasadun.com

1–10 of 54 posts

Re: Swift: Things I really wanted that won’t make it

#4
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.

Re: Swift: Things I really wanted that won’t make it

#5
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 my only fear though really. Rarely do I personally do a lot of subclassing unless I absolutely have to or it really does make sense to.

Re: Swift: Things I really wanted that won’t make it

#6
The "with" method cascades could be even nicer if they were VB-like, which needed a . prefix.

Example:

   with obj {
       .field = abc;
       xyz = .foo(12);
       .method();
   }
This would have several advantages:

* easy for syntax completion

* can access names that are not in the innermost with-scope

* can access names at outer with-scopes using .. and ... etc

Re: Swift: Things I really wanted that won’t make it

#7

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…

Agreed. I don't even like the fact that you can turn off subclassing, that's very un-object-oriented IMHO.

Re: Swift: Things I really wanted that won’t make it

#8

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…

Apple's ability to release a Swift-based SDK that uses "final" and "final" being the default for classes in Swift are completely orthogonal concepts.

Apple could (and should, I think) release future SDKs that use all-final classes and require composition instead of the incredibly fragile base classes that currently make up UIKit and Foundation - they'd just add the "final" keyword.

Since UIKit is inheritance-based currently, in a final-by-default Swift, it would be imported as "subclassable", "nonfinal", or whatever. Nothing would change other than the default for newly-written Swift code.

Re: Swift: Things I really wanted that won’t make it

#9

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…

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

Re: Swift: Things I really wanted that won’t make it

#10
> 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 unfamiliarity with Swift, I may be mistaken on some obvious things).

E.g. Instead of

    with let task = NSTask() {
        launchPath = "/usr/bin/mdfind"
        arguments = ["kMDItemDisplayName == *.playground"]
        standardOutput = pipe
        launch()
        waitUntilExit()
    }
do

    with let task = NSTask() {
        $0.launchPath = "/usr/bin/mdfind"
        $0.arguments = ["kMDItemDisplayName == *.playground"]
        $0.standardOutput = pipe
        $0.launch()
        $0.waitUntilExit()
    }
That way if you want to use some non-related variabled within the block, or the output of an attribute or method as the input of some other attribute or method, it's not ambiguous.

1: http://design.perl6.org/S11.html#Versioning

Post reply on HN