Just finally getting to catching up on this. Like others, I'm very excited about the possibilities, and this looks like a great start!
I do hope we'll have an opportunity to iterate on the API design aspect a bit. At first blush I was concerned that the initial design of Type
doesn't use a label to distinguish between initializing from a value or from a type, which is something that we took care to do with other APIs (such as MemoryLayout.stride
, etc.). I do worry about whether confusion could arise when the value is a type.
Supposing we were to (say) distinguish Type(Foo.self)
from Type(of: fooInstance)
, a question arises which actually is present even with the API as pitched: users might rightly be confused about the distinction between type(of:)
and Type(...)
âand more fundamentally, as you mention later, the distinction between a type and a Type
.
While I empathize with not just sticking the API directly on Any.Type
and possibly even all concrete types, I don't think that's the only alternative to inventing a top-level Type
that is distinct from the actual type:
Have you considered a design where, for example, we have a reflected
property on types as an "umbrella" for reflection (in the same vein that we have lazy
in the language for lazy sequences)? That is to say:
for field in Dog.reflected.fields { ... }
// ...as opposed to:
for field in Type(Dog).fields { ... }
// `Type(Dog)` isn't `Dog.Type` or `Dog`...
// That's a lot of different "types" to understand!
// ...or:
for field in Dog.self.fields { ... }
// Now we avoid creating yet another `Type`, but either we make
// `self` even more "magical" or we pollute code completion for
// the concrete type.
This would moreover provide a nice symmetry where Dog.self
gives you the type and Dog.reflected
gives you the "reflected type." From a value, one would then write type(of: dog).reflected
.
Other than that design question I would just echo previous commenters regarding the "partial type" terminology.
I'd also point out that while Field
is nice and short, I believe the user-facing terminology (in TSPL, say; and indeed in the just-pitched declaration macros document) has called it a "stored property," UI code would use "field" to mean something very different, and I think there is value in trying to maintain consistency here throughout our documentation and APis.
Anyway, bravo on the overall pitchâvery exciting that it exposes new possibilities for the language in an exciting way.