IMPORTANT: Evolution discussion of the new DSL feature behind SwiftUI

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?