snarwin at gmail.com
Sun Aug 2 16:38:30 UTC 2020
On Sunday, 2 August 2020 at 04:08:00 UTC, Bruce Carneal wrote:
> I was thinking more about gaining access to a mutable form
> which could be converted to/from concrete types as represented
> by the compiler under the hood rather than the current methods
> of creating types in the source. Note that "mixin" reduces to
> the others above and the others, of course, reduce to the
> compiler's internal form.
> Yes, unrestricted type mutation capability is a non goal. So
> today we have a large and growing zoo of forms that we can
> utilize to work with types. A mutable class convertible
> to/from whatever the compiler is using "under the hood" might
> be a better way. It might be used to implement the zoo while
> limiting further special casing. Switching metaphors, we'd
> have less unsprung weight going forward.
Correct me if I'm wrong, but it sounds to me like what you have
in mind is something like this:
// type function
b.kind = Kind.struct;
foreach (T; Ts)
b.addMember(T, ""); // anonymous member
That is, we have some mutable representation of a type, which we
can manipulate via some compiler-defined API, and once we're
done, we convert the result to a "real", immutable type, which
can be used in other parts of the program.
I can see how this sort of thing might be useful. Indeed, if you
generalize this design from just types to *all* kinds of AST
nodes (FunctionBuilder, ExpressionBuilder, etc.), what you end up
with is essentially a procedural macro system.
The problem is that D already has features for performing these
kinds of AST manipulations: static if, static foreach, and
mixins. From a language-design perspective, adding new features
that duplicate the functionality of existing ones is generally
not a good idea.
Rather that attempt to *replace* D's existing metaprogramming
features with something entirely new, I think it would be much
better to *extend* them with language features that allow us to
overcome their current limitations.
> Factoring out naming from the "anonymous" structural aspects of
> types seems like a good way to go. If people want to match on
> type structure for some reason, great. If they want to create
> ginormous names, well, OK.
I don't understand what structural vs. nominal typing has to do
with the rest of your post.
More information about the Digitalmars-d