Re: Dynamic Variant Record Creation

[Adam Beneschan <adam@irvine.com>]

On Mar 16, 1:31�pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Warren <ve3...@gmail.com> writes:
> > Of course. But it is not conceptually inconceivable to
> > check this at runtime and realize that the value I handed
> > out will work with what was provided. If not, then
> > raise an exception.
>
> Not inconceivable, I suppose, but that would be a huge language
> change. �It would require totally rethinking the overload
> resolution rules, because currently there's a fundamental
> principle that the type of an aggregate is determined by
> context (ignoring the components), and once that type is
> known, the component expressions are resolved knowing
> their types.
>
> I really don't think you want to do overload resolution at
> run time.

Actually, I don't think overload resolution would be an issue, as long
as the aggregate (or at least the components that are in variant
parts) is specified using named associations.  As you said, the
information about the components isn't used to determine the expected
type of the aggregate.  Once the type is determined from context, the
names of the variant components would be enough to determine which
variants must be present, and therefore what the allowable values of
the governing discriminant(s) are.  (And, of course, if two component
names are specified that cannot exist at the same time, it's already
illegal.)  However, this wouldn't work if positional notation is used,
and this inconsistency (discriminants must be static if components are
in positional notation but need not be if they use named associations)
would be enough reason for me to say this is a bad idea, if I didn't
already think it was, which I do.

                                    -- Adam