Is SwiftUI part of the Swift language or not?

I understand that the evolution of Swift goes both by the highway, and by the byway.
And I feel uneasy about that dual direction, and have difficulty understanding the reasoning that goes with it.

In order to make clear why I have that feeling let me explain.

  • The highway is the official Swift documentation « The Swift Programming Language » as one can find and read it in iBooks.
  • The byway is the « macro language » growing more with function builders, project wrappers and much much more.

A question was asked some time wether SwiftUI discussions had their place on swift.org was raised some time ago, and a couple of the following messages concluded that no, probably no/yes.

It illustrates how confusing it is.
« I’ll answer the part that is related to Swift syntax, and then a little tangent about SwiftUI. However, it should not be treated as a signal/encouragement to post SwiftUI related question on this forum. Questions purely about SwiftUI should still be in Apple Dev's forum. »

In the same conversation one hears even neater things.
« We encourage questions that are just about using Apple frameworks like SwiftUI to be asked on the Apple developer forums 5. »

So one way to understand this can be : « SwiftUI is NOT part of Swift. »
Another way to understand this could be: « I do not encourage questions about this person, he’s kind of family but we do not like to talk about him.

Additional confusion, for me, comes from proposals and discussions that lead to new features, largely SwiftUI oriented. Even if admittedly others areas of application exist.
And then after building for SwiftUI, trying to relegate the result as a second zone citizen that is an unwanted topic of conversation.
Or as not part of the language.

I would love to hear more generally what the community thinks, especially since I have seen expressed wishes for SwiftUI for Linux and Windows.
So I do no think that it can be resumed as an Apple Framework issue.

To put it differently:
Does the @ in front of a language keyword mean the it marks the beginning of a macro?
Or should it identify a new keyword and is part of the language?

Is the spelling the most important factor?
Or is it the measure of the impact of the possibilities of development the most important factor?

2 Likes

Apple has asked us to forward questions about using Apple's frameworks to their developer forums rather than allowing these forums to become a generic alternative for discussing programming for Apple platforms. That's a request we have to take seriously. As a result, most of the "Using Swift" questions here are either abstract or focused on non-Apple applications. That doesn't mean that Apple app programming is in any way disfavored or dismissed; that is very much the core of the Swift community.

12 Likes

My general understanding is that if the @ is followed by an upper case character (eg “ViewBuilder”) these features are defined in user or framework code. In this case, it’s SwiftUI framework providing the implementation of the ViewBuilder builder functionality. When it is followed by a lower case, this is a sign of a language-defined feature.

Result builders and property wrappers are not macros in the compile-time sense. Property wrappers and result builders run at runtime, (though result builders are implicitly called by the builder system).

There are exceptions to this. For example, @NSCopying. These case predate the precedent for case-differentiation.

Thank you for the clarification.

Hmm, do you know where I might find documentation on this?
( I find the use of this "prefix" highly confusing. Ex if you search "@State" in the documentation you'll find nothing. Remove the @ and search for "State". Lo and behold you get the full documentation for State, and bindings.)

1 Like

Attributes applied to properties, which are formed by @ followed by a property wrapper type, are thoroughly documented in the Swift programming language guide.

SwiftUI is not a part of the Swift language in the same way that any other library is not a part of the Swift language (other than the standard library, which could be considered "special" from some perspective). There's nothing special or "magical" in SwiftUI that can't be built in any other library, as was shown in SwiftWebUI, OpenSwiftUI, and Tokamak (disclosure: I'm a co-maintainer of the latter).

The only things that are prefixed with @ are attributes and property wrappers. Swift has a limited number of attributes, so anything that's not attribute would be property wrapper.

The fact that property wrapper uses upper camel-case is only a convention that follows from the fact that property wrapper are types (struct/class/enum), and types should use upper-camel case as per API design guideline. Nothing stops you from creating a property wrapper @foo, but I wouldn't recommend breaking the convention without good reasons.

You could also say that property wrapper is a user-defined attributes, but that wouldn't help much when searching for documentation.

2 Likes

That’s my understanding as well. Generalizing the pattern of allowing user-defined "attributes" starting with @ has been discussed under the term "custom attributes" on the forum. As far as I know it hasn't been formalized yet, but here's a post from @Douglas_Gregor that summarizes the intent:

Using types for attributes, and their initializers to build values, means that we can build on existing infrastructure for (e.g.) runtime inspection (use as? dynamic casting), any future static-reflection facilities (which of course have to work with user-defined types and values thereof), and simplifies the problem space.

I don't think that we should allow just any type to be used as an attribute, though: we should require that types be marked with a (built-in!) attribute to indicate that the types themselves can be used as custom attributes.

I'd suggest that we reserve all attribute names starting with a lowercase letter or an underscore for the compiler; that fits well with Swift's API design guidelines suggesting that type names start with an uppercase letter.

2 Likes

Swift is open-source and cross-platform. I think it is fair to say that anything that does not possess those properties should not be considered part of Swift, even in the sense of being a useful tool.

Personally, I think Apple should make a concerted effort to bring newer libraries like Combine and even SwiftUI up to those standards. Until then, design patterns using them cannot be widely adopted by the Swift community without clashing with the goals of the language.

1 Like