SwiftUI relies on implicit return statements, property wrappers, keypath member lookup and function builders. All but the last have gone through the evolution process and are implemented completely in Swift 5.1. The function builders feature has been pitched and is going through the process; the current implementation uses an underscored attribute. The implementation might change but it will not affect client code, only the declarations of the relevant types in SwiftUI. This means you can’t define your own function builders today without a future compiler possibly breaking source compatibility with your implementation — but other than that there’s no magic in the SwiftUI API beyond the language itself.

Yep. The funny thing is that if you try to use this new automatic type-erasure stuff for anything but SwiftUI, you will soon encounter compiler errors like “`some` types are only implemented for method return types or computed property accessor return types”. Lol.

So e.g. you can’t use `some`-typed variables or stored properties.

The `some` keyword declares an opaque result type ([0]), which means "this function has a concrete return type, but the identity of that type is a hidden implementation detail." An opaque result type can be used like a generic type -- the compiler doesn't know the exact type, but it does know that calls to the function will always return the same type (which is important when working with protocols such as `Equatable` that have associatedtype or Self requirements).

A `some`-typed variable or stored property wouldn't make any sense because it would be a variable that has a concrete but unknown type. You can't assign something to such a variable, because there's no way to know whether the value you're trying to assign matches the hidden concrete type of the variable.

Perhaps the "automatic type-erasure" feature you're wanting is actually generalized existentials ([1])? Generalized existentials would allow you to declare a variable whose type can be "any Equatable", rather than "some (specific but unknown) Equatable", and the compiler would allow you to "open" the existential and use it like a generic type (without throwing the "protocol can only be used as a generic constraint because it has Self or associatedtype requirements" error).

[0]: https://docs.swift.org/swift-book/LanguageGuide/OpaqueTypes.... [1]: https://github.com/apple/swift/blob/master/docs/GenericsMani...

You definitely can have a 'some' type property[0]. Computed properties work just like functions do. Stored properties just need a value assigned, like so:

    let strings: some Collection = ["hello", "world"]

[0]https://github.com/apple/swift-evolution/blob/master/proposa...

I haven't really dug into SwiftUI yet, but I'm not quite sure what you're describing. I'd love to see a concrete example of something you think you can't replicate with your own type.

I tend to run into these when weaving a lot of SwiftUI + non-SwiftUI code together.

A simple example: [0]. There are workarounds for this specific issue, but trying to do complex stuff sometimes surfaces inscrutable limitations that I can't quite figure out. And with no documentation relevant to a particular case, no Google hits, not even on Apple's forums, and the uncertainty of error messages, I'm not even sure if I'm doing something wrong or it just can't/shouldn't be done. I have to try random things until it works...until it doesn't.

I'm currently experimenting with a SwiftUI layer for a game engine [1], and running into weird undocumented differences between macOS and iOS (like view backgrounds clipping at stack container edges on macOS but not on iOS) that I can't be sure if they're bugs or what. Still, I love SwiftUI.

Also see EmptyView [2]

[0] https://gist.github.com/ShinryakuTako/5a7b32bbf4f4c3874439c2...

[1] https://github.com/InvadingOctopus/octopuskit

[2] https://forums.swift.org/t/how-do-views-like-emptyview-confo...

I assume your goal with [0] is to be able to say `ViewContainer()` and have it wrap an `EmptyView`? You can do that like the following:

  class ViewContainer<ViewType: View> {
      var view: ViewType
      init(view: ViewType) {
          self.view = view
      }
  }
  
  extension ViewContainer where ViewType == EmptyView {
      convenience init() {
          self.init(view: EmptyView())
      }
  }

With this code, writing `ViewContainer()` will produce a `ViewContainer<EmptyView>`. Writing `ViewContainer<Text>()` will fail with an error (as expected).

Note that since this is statically-typed, the following will fail:

  let container = ViewContainer()
  container.view = Text("wat")

If you want to be able to do that, you'd have to write something like

  let container = ViewContainer(view: AnyView(EmptyView()))
  container.view = AnyView(Text("wat"))

I love the extension idea, noting that for later. :)

But I do need to be able to change the view during runtime, so I settled on just type-erasing to AnyView for now.

If you have a set number of possible view types you could in theory have it hold onto an enum of the different types.

I think the issue is that a variable's type can't be set by the outside (via the template parameter ViewType) and by the inside (to be of type EmptyView) at the same time. You have to decide.

Your workaround is to use the AnyView type I guess. Or a conditional with either EmptyView or the template type (displayed).

What would be the name of the feature that allows you to use a default template type if no argument is given to figure out the type to use?

> Your workaround is to use the AnyView type I guess.

Yes, I made the init generic instead of the type, and made the property an AnyView, but I've read that AnyView may decrease performance (probably because of reasons discussed in this post's article.)

True. You could work around it by conditionally extending your ViewContainer to have a default constructor (init()), if the type is EmptyView. Then you can write

    var viewContainer2 = ViewContainer<EmptyView>()

But that's probably not what you want is it. Default generic arguments aren't implemented yet, see (https://stackoverflow.com/questions/42015081/can-i-assign-a-...). It would have possibly removed the <EmptyView> aspect. So you always have to give a type to ViewContainer, if you provide no way for the compiler to infer it.

> var viewContainer2 = ViewContainer<EmptyView>()

Yes, that would be a workaround for myself, but for a game engine's API, it'd be ugly to require users to write that every time. :)

And there are cases where they might not even know the type.

It seems the compiler might be smarter than I thought he is (see a poster above), if so I learnt something new. :)

And it seems I didn't understand your problem, you wanting a variable that can change it's type instead of just some syntactic sugar, hmm.

I believe SwiftUI's not doing anything that isn't available in the public version of Swift. There may be some stuff that's still going through the proposal process, not sure.

His problem might be that certain features (of SwiftUI) you cannot hook yourself (your own implementation) into (since they are based on protocols which cannot be implemented yourself since they are not public and so not meant to be implemented by yourself), which makes it, at times, necessary to use workarounds to public-facing apis.

Or it might be something else.

You're correct, part of the problem is indeed that, though I'm not completely sure myself.

But how do things like EmptyView work? How do they conform to the View protocol without having a body property (that must also be a View)?

I think it has a body type [0] (Never). And since a default implementation is provided [1] the compiler probably does not complain. This default body implementation does likely not draw anything, but that's just guessing.

[0]: https://developer.apple.com/documentation/swiftui/emptyview/... [1]: https://developer.apple.com/documentation/swiftui/view/32785...

It's because of Body's type:

    public struct EmptyView: View {
        @inlinable public init()
        public typealias Body = Never
    }

Because Body is Never, you can't access EmptyView's body property.

Can we write a protocol + type like that?

https://forums.swift.org/t/how-do-views-like-emptyview-confo...

I don't see why not. When I trick it into calling `body` on an EmptyView, I get this runtime failure:

> Thread 1: Fatal error: body() should not be called on EmptyView.

So I don't think the implementation is doing anything beyond the fatalError() call from that forum thread. At least not at this point in time.