pitch: rename the "Child" types

[distractedlambda]

I can understand the origin of the name choice Child, but I dislike it for a couple of reasons:

• It doesn't read well in code; I don't think of the pointed-to type of a pointer as it's "child"
• It's unnecessarily ambiguous when you don't know what the type on the left-hand-side of the . 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:

• For pointers, Pointee, Target, or Dereferenced, etc.
• For optionals, Unwrapped, Inner, Value, NonNull, etc.
• For arrays, Element, Item, etc.
• For vectors, Element, Component, Scalar, etc.

[marler8997]

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.

[andrewrk]

Child is actually deprecated, to be future proof use @typeInfo. See also std.meta.Child.

[distractedlambda]

@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.

[marler8997]

Yes, using @typeinfo allows for both.

[andrewrk]

This affects, e.g.

zig/lib/std/builtin.zig

Line 188 in 702398d

child: type,

Note also the naming convention of types should be respected.

[ghost]

• For pointers, Pointee, Target, or Dereferenced, 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

[data-man]

What's problem?
std.meta.Elem is already exists.