Add '_spi(TokamakCore)' to ideally internal public members.

[filip-sakel]

This PR adds _spi(TokamakCore) to the modules:

1. TokamakCore
2. TokamakDOM
3. TokamakGTK
4. TokamakStaticHTML

The attribute is applied to:

1. All View bodies in TokamakCore — either primitive or regular like Color
2. ViewDeferredToRenderer bodies
3. ParentView children members
4. View modifiers (such as _onMount(perform:))
5. Other members of types (like Color._withScheme, and _AnyApp._launch)

The attribute semantics (from my brief testing)

1. It can only be applied to public declarations
2. It ensures that every SPI declaration is exposed only by other SPI declarations (i.e. @_spi(Module) public enum A {}; public var a: A is illegal)
3. Regularly importing a library prohibits clients from accessing SPI declarations that are not protocol witnesses (with an error).
4. Regularly importing a library "discourages" clients from accessing SPI protocol witnesses by hiding them from the autocompletion suggestions (i.e. users can still access body of Text, but autocompletion hides it).
5. For a declaration marked with @_spi(Module), a client has to write @_spi(Module) import Library in order to normally access such SPI declarations.

[MaxDesiatov]

Could you apply SwiftFormat as swiftformat . in the project directory to get rid of trailing whitespaces? You can also install a pre-commit hook as described here, which will apply formatting fixes automatically for you before you commit.

[filip-sakel]

Thanks, I had forgotten that.

[MaxDesiatov]

Seems legit 👍

[carson-katri]

Is it possible to do the neverBody with @_spi in one place with an extension? Like:

extension View where Body == Never {
  @_spi(TokamakCore)
  var body: Never { neverBody("\(Self.self)") }
}

Then we can just use typealias Body = Never in the individual Views. That way if we ever want to change the way neverBody/_spi is used we can easily do it.

[filip-sakel]

Yes it is. I introduced a PrimitiveView protocol to which all Never-body views in TokamakCore conform:

/// A `View` that offers primitive functionality, which renders its `body` inaccessible.
public protocol PrimitiveView: View where Body == Never {}

public extension PrimitiveView {
  @_spi(BubbleCore)
  var body: Never {
    neverBody(String(describing: Self.self))
  }
}

Then we can just use typealias Body = Never in the individual Views.

I added a new protocol instead of a conditional default-implementation on View because of type inference. This could perhaps work if type inference took into account SPI extensions only in the declaring module (and of course modules with @_spi(Module) import ...). Still, marking extensions SPI was introduced in 5.4, and its semantics haven't been fully fleshed out, so I think the safer option is to go with a new protocol.

[filip-sakel]

I am also in a dilemma when it comes to whether ParentView.children should be underscore-prefixed. In the current implementation, ParentView.children members are marked SPI to match SwiftUI's not having Button(...).children. I think solidifying this design direction with the more apt name _children, will alleviate user confusion and improve consistency. What do you think?

[mortenbekditlevsen]

I am all for the addition of PrimitiveView. I am doing some experiments where I do some recursion through the view hierarchy and need to have the Never-body views marked by a protocol. I call it BuiltinView inspired by objc.ui Swift Talks.

Regarding ViewDeferredToRenderer I was initially confused by that name since I interpreted it to mean Never-body views, whereas it's actually a workaround to supply a body for a never-body view. So I don't think it's actually being deferred to the renderer, but to some other view...

[MaxDesiatov]

I'm going to significantly refactor or even get rid of ViewDeferredToRenderer in the near future anyway. The problem is that you can't have multiple ViewDeferredToRenderer conformances existing in the same app and working in some sane way. The compiler doesn't give any warning about conflicting conformances and just picks one according to some undocumented priorities. This prevents us from using the TestRenderer module together with any renderer in the same test bundle, and there can be only one test bundle in a given SwiftPM package.

The conflicting conformances isssue and inability to use any renderer other than the test one is pretty severe in my opinion. Most probably the logic currently handled by ViewDeferredToRenderer is not going to be implemented with protocol extensions at all. IDK maybe through plain enums and switches?

[MaxDesiatov]

ParentView.children members are marked SPI to match SwiftUI's not having Button(...).children. I think solidifying this design direction with the more apt name _children, will alleviate user confusion and improve consistency. What do you think?

This makes sense to me. ParentView is a protocol with internal visibility, or at least none of the renderer modules re-export it, so users weren't able to see it anyway, or am I missing something?

[mortenbekditlevsen]

Excellent - I also think that most uses of ViewDeferredToRenderer that I have seen could be refactored away.

Regarding 'package' level access control, have you seen this pitch?

https://forums.swift.org/t/pitch-swift-package-access-control/45174

[MaxDesiatov]

Thanks for sharing it, this seems like a good pitch that could help us clean up things a bit!

[filip-sakel]

This makes sense to me. ParentView is a protocol with internal visibility, or at least none of the renderer modules re-export it, so users weren't able to see it anyway, or am I missing something?

Currently, a public type conforming to a public protocol requires that this protocol's witnesses have a public access level. This, though, doesn't mean that the visibility of protocol witnesses is tied to the visibility of that protocol. For instance, the property public var children: [AnyView] of a ParentView-conforming Button type is visible to clients even when the ParentView protocol is not. Thus, I marked children properties of ParentViews SPI in TokamakCore — before this change clients could see children properties in the autocompletion list.

[mortenbekditlevsen]

Great work!
I look forward to using PrimitiveView in my own experiments. :-)

[mortenbekditlevsen]

Is there a reason that it's conforming to both PrimitiveView and View? Is the former not a refinement of the latter?

[filip-sakel]

Yes, conditionally conforming a type to a "refining" protocol (such as PrimitiveView) requires that either that type have separate conditional conformances (i.e. extension Group: View where Content: View {} and then the PrimitiveView conformance), or that both conformances be explicitly written (as is done above).

Also, I have no preference as to whether the above is written as PrimitiveView & View or PrimitiveView, View; whatever you prefer.

[mortenbekditlevsen]

Is there a reason that the body implementation from the PrimitiveView conformance is not good enough?
There probably is, but I'm not at a computer, so I can't try it out right now. :-)

[filip-sakel]

It's just that a Never instance can, as the name suggests, never exist. Thus, I thought it would be misleading to use the primitive view conformance. Not to mention that relying on the PrimitiveView default implementation causes problems with Never-body scenes (for reasons I don't fully understand).

In my opinion, instance members of no-case enums, like Never, should non require a body anyway. This behavior is actually in place for functions taking no-case enums, meaning that func a(_: Never) -> Int {} is perfectly valid.