IMPORTANT: Evolution discussion of the new DSL feature behind SwiftUI

I'd just like to show my support here. Like basically every heavy Swift user, I was super happy in seeing SwiftUI, but also surprised and a little concerned, because it seemed to clearly rely on either:

  • some "unannounced" Swift feature;
  • hacks and magic.

But I'm actually thankful that it's going to be about a new feature, developed internally over progressive iterations, and it's great to see an actual pitch and draft proposal, for discussing details and move towards the final shape of this.

To me it's extremely important that there's a motivated core team that ultimately decides what goes into Swift, which of course means both what doesn't go, and what goes no matter what: it helps keeping the language consistent and opinionated, and I don't see this as a restriction on what the community can achieve as a whole.

10 Likes

I want to express my gratitude for what the core team and Apple has done here! I think it’s great!

I also think the process used is something we as a community should get used to.

It’s the best of both worlds - big money/muscles, long term commitment and vision together with the many eyes/opinions/use cases and ability to get your voice heard with the open source community.

Puritan open source advocates will not like it - but I think you are doing everything right here, and getting the best of both worlds!

I for one like these huge, surprise announcements at WWDC - and wouldn’t like it to change!

So a huge thank you for your great work!

13 Likes

My $0.02
Similar to SwiftNIO and Swift-Log I see the Core Team as iterating on things and releasing them to the community. The fact that it was even released to the community for review is a sign of good-faith by the team to engage the community. Most folks have already said that they can't use it because it doesn't support iOS 12, so unclear why there is so much flack. Even if SwiftUI itself doesn't become open source, DSL as a concept can be used by the community to do great things.

10 Likes

I followed a number of language development forums over the last 30 years.
I can only say that most of them had, and benefited greatly from, a "benevolent dictator".

1 Like

i know c++ and i used to think c++ was just an excuse but today i encountered an auto tryTypoCorrection = [&] { }; in the swift compiler and that was when i decided to leave the c++ be

3 Likes

Off-topic: That's just an empty lambda that captures referenced variables by reference.

1 Like

Note that you can’t usefully reassign that variable, because it’s an auto and different lambda’s have incompatible types.

It’s a local func, and if it could be declared that way it would be.

I think C++ is a flawed language in many ways, but its problems have taken on a life of their own in internet discourse beyond all connection to the language itself.

10 Likes

I don't really mind the Core team deciding things unilaterally. Language design is not a democracy and shouldn't be. If anything, I think that sometimes too many people try to influence Swift in their own way, leading sometimes to inconsistent language design.

However, in this case, I echo @Max_Desiatov's concerns about the language losing focus. In order to introduce a feature like SwiftUI, it seems that so many low-level design decisions would need to be made first, that the risk of unduly rushing these decisions seems quite high.

To me (admittedly as a non-app developer), it looks like Apple is reprioritising important development resources in order to satisfy some marketing promises, instead of fixing and improving core issues with the language first.

But it's Apple's decision to make, just as well as it's every developer's (or company's) decision whether to want to invest in Swift.

14 Likes

Honestly I’m stoked to have some great new features announced to spark more interest in the Swift ecosystem!

My main concern is, if there are language features being used by Apple (E.g. in SwiftUI), I would like to be able to use them myself in order to recreate something similar or, if needed, “polyfill” the feature for other platforms. If that’s possible, I’m happy. Of course, open sourcing SwiftUI would be even better, but I don’t see it happening.

I just want to say thank you to all contributors from Apple and from the wider Swift community for your hard work on Swift.

Honestly, it looks strange for me to see a feature in the latest beta Xcode version which has not been reviewed in GitHub yet.
As for the announced features (@ViewBuilder and Combine), I am really scared of the evolution of Swift. Starting from pretty useful compiler annotations for Objective-C compatibility, complication flags, and some features like @discardableResult, we have reached a Java-style annotation, @ViewBuilder, applying to function’s arguments. Don’t you think there should be a more consistent solution? For instance, improving syntax for arrays, to return from the Swift UI stacks’ closures an array of views?

I love Swift and its way to make my code safe and easy to read, but adding annotations and using type erasure classes in Combine look like we are going to completely drop its unique features and make Java 2.0. Moreover using static methods for such operations is more about procedural programming, not OOP or POP.

I mean I think new features should improve and complement POP/OOP way chosen for our language.

9 Likes

Something that I’d like to know is whether the Core Team considers certain aspects of this proposal (and the property wrappers proposal) effectively fixed. There are discussions in both threads still proposing new syntax that is contrary to many of the WWDC presentations and current Xcode beta. Should the forthcoming parts of the evolution process treat these proposals as we would any other, or is the Core Team only meaningfully considering certain types of feedback, a la the bike shedding discussion following the “callable values” acceptance?

2 Likes

I think it’s very important for everyone to be aware of the difference between swift-the-language and various frameworks built on top of Swift.

AppKit and UIKit frameworks have never been open source, and it’s not realistic to expect them to be open source even if they were rewritten in Swift. They are Apple’s proprietary frameworks. SwiftUI is just another framework like this. At least that’s how it is right now. Nothing has changed in this approach. If anything, SwiftNIO and LSP work is very gracious from Apple to have been open sourced.

The infrastructure (plumbing to build DSLs) on the otherhand is swift-the-language stuff, and is appropriately going through SE. SwiftUI can exist even without it, as non-public extension, but the benefit of SE is allowing to build other DSLs, or 3rd party crossplatform SwiftUI. Also, as community refines the proposals, Ultimately also propretary SwiftUI benefits from the better plumbing.

Even Android has proprietary stuff written on top of the language, it’s never pure open source play.

5 Likes

I do agree with you pretty much on every point there. In fact, I'm not even sure if you're trying to elaborate on my semi-joke, or if there's some misunderstanding.

Probably somewhat misunderstood your joke, but also responding to this thread in general, not only to you...

1 Like

I think JetBrains already did that :wink:

I'm always up for criticizing Java :innocent:, but just because it uses Annotations (sometimes poorly), that doesn't mean they're inherently bad. The fact is Swift needs a way to enable some amount of compile-time met-programming. If anything, this is something you could argue Java's done well and one of the bigger reason it's so dominant in so many different use cases.

For behavior that's straightforward /generalizable, protocol adherence works well (eg. Codable, CaseIterable) . However, that capability is currently inaccessible to users, and other than simple Code generation it doesn't lend itself all that well to more complex issues that require user-input. (also on the more "Magical" side of the language). Even with Codable, I would bet the vast majority of the use of CodingKeys could be replaced by @CodedWith(key: String) and IMO it would be a much better API. than declaring a magical enum.

Unfortunately the desired use cases for annotation-like-syntax can't be enabled by tweaking some APIs. Having the ability to add meta-information about Types/Properties/Parameters is necessary for many things. It's so badly needed that projects like ObjectBox put annotations in comments, which I think everyone can agree is far from ideal.

The once you add it you can't remove it reality means things should be added with great care. I would love there to be better alternatives to Annotations, but I have yet to see one outside of specific use cases.

5 Likes

Sorry if my comment looked like criticism, I absolutely agree that sometimes Java annotations are useful and suitable. However, Java provides an entire toolbox to work with annotations, and, what more important, does not change the syntax of code you want to annotate. This @ViewBuilder definitely does it, that closure becomes something that looks like an ordinary closure, but requires own syntax and has own limits. This inconsistency, I think, makes the code less readable and predictable.

5 Likes

After chewing on this a bit I think I understand what you're saying, and probably agree. @FunctionBuilder does feel a bit too "Magical" to me and it seems like the feature may be better implemented by adding some sort of generalizing capabilities to protocols. But that's for the other discussion thread :slight_smile:

1 Like

There's already a number of HTML DSL's out there using Swift that look like pretty good starts. And I'd actually been thinking of starting a couple other projects around using Swift as a DSL for a few other topics (e.g. build systems and API documentation).

Swift is an amazing language in itself but the conciseness and minimization of syntactic "cruft" it offers make it a wonderful language for this purpose.

we are supposed to use functional programming style like forEach functions instead of for/while, aren't we?