Open distractedlambda opened 5 years ago
Note that if they all use the same name, then generic code can be simpler in some cases:
fn foo(a: var) @typeOf(a).Child { ... }
How would you write this with your proposal?
Also, If we had a different name for each type of array, wouldn't it be harder to remember the specific name for each one? Child
is kind of an odd name, I wouldn't mind changing it but I'm not seeing the benefit of creating a unique name for each type of array.
Child
is actually deprecated, to be future proof use @typeInfo. See also std.meta.Child
.
@marler8997
I can see your point, although if the plan is to switch to implementing these sorts of "type traits" in user code atop @typeInfo
, then we could reasonably have both at the same time. We could all have Child
functions and Element
functions and Unwrapped
functions and whatever else suited our particular fancies.
Yes, using @typeInfo allows for both.
This affects, e.g. https://github.com/ziglang/zig/blob/702398dd0e2188ad03b3c4760c08ea673573489e/lib/std/builtin.zig#L188
Note also the naming convention of types should be respected.
For pointers,
Pointee
,Target
, orDereferenced
, etc.For optionals,
Unwrapped
,Inner
,Value
,NonNull
, etc.For arrays,
Element
,Item
, etc.For vectors,
Element
,Component
,Scalar
, etc.
You know, Element
would work for all of these.
Rly maks u thonkum
What's problem?
std.meta.Elem
is already exists.
I can understand the origin of the name choice
Child
, but I dislike it for a couple of reasons:.
is, and I think unique names would improve readability in-practice, even if only slightly.I therefore propose that the
Child
types get renamed to some set of new (and unique) names. I don't think it matters so much what the exact names are, but rather that they are unique, and that they have something to do with what the type represents. A few suggestions:Pointee
,Target
, orDereferenced
, etc.Unwrapped
,Inner
,Value
,NonNull
, etc.Element
,Item
, etc.Element
,Component
,Scalar
, etc.