Walter, have you considered adding variants to the language?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a3g9cv$19bk$1@digitaldaemon.com...
> Walter, have you considered adding variants to the language?

Yes. Generic programming is accomplished either with templates or with variants. I see no compelling reason to support both. Variants are easy to support, but you lose all type checking with them and they have a high runtime cost. That's ok for scripting languages, but unacceptable for a high performance langage, so it'll be templates.

"Walter" <walter@digitalmars.com> wrote in message news:a3gbov$1got$2@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a3g9cv$19bk$1@digitaldaemon.com...
> > Walter, have you considered adding variants to the language?
>
> Yes. Generic programming is accomplished either with templates or with variants. I see no compelling reason to support both. Variants are easy to support, but you lose all type checking with them and they have a high runtime cost. That's ok for scripting languages, but unacceptable for a
high
> performance langage, so it'll be templates.

Well there are some things not covered by templates that variants can do. For example, a function that returns a string or an integer. With variant, it could be:

    variant foo(int x)
    {
        if (x > 0)
            return x;
        else
            return toString(x);
    }

I don't see how something alike can be done with tempaltes or function overloading. Also sometimes an array with elements of different types is needed. For example:

    void print(variant[] args);
    ...
    print(["Hello, world!\n", cast(wchar[])"UNICODE", 666, 123.456, true]);

Templates won't help here, either. Personally, I'd prefer to have both variants and templates. It would be even better if variants were COM-compliant - one more step to complete COM support.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a3gft8$1jhm$1@digitaldaemon.com...
> It would be even better if variants
> were COM-compliant - one more step to complete COM support.

Why not just use the COM variant struct?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a3gft8$1jhm$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a3gbov$1got$2@digitaldaemon.com...
> >
> > "Pavel Minayev" <evilone@omen.ru> wrote in message news:a3g9cv$19bk$1@digitaldaemon.com...
> Well there are some things not covered by templates that variants can do. For example, a function that returns a string or an integer. With variant, it could be:
>
>     variant foo(int x)
>     {
>         if (x > 0)
>             return x;
>         else
>             return toString(x);
>     }
>
> I don't see how something alike can be done with tempaltes or function overloading.

That's what I meant by you lose all type checking with variants. Aside from interfacing to COM, why use variants? When I've used them, there were always unanswerable issues like what do you do when you add a float and a string? Then there was always the problem (I ran into with COM) of getting some nutball variant type back that you have no idea what to do with - like I expect a number, and I get a VT_DISPATCH. Or I want to pass a null type, do I do a VT_EMPTY or a VT_NULL? COM interfaces are full of lack of documentation about what variant types are allowed. Wierd crashes happen when the COM programmer forgot that he needs to deal with VT_R4. I guess I've just had bad experiences with variants.


> Also sometimes an array with elements of different types
> is needed. For example:
>
>     void print(variant[] args);
>     ...
>     print(["Hello, world!\n", cast(wchar[])"UNICODE", 666, 123.456,
true]);
>
> Templates won't help here, either. Personally, I'd prefer to have both variants and templates.

You can get close to that with the union initialization syntax.

"Walter" <walter@digitalmars.com> wrote in message news:a3gh39$1k44$1@digitaldaemon.com...

> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a3gft8$1jhm$1@digitaldaemon.com...
> > It would be even better if variants
> > were COM-compliant - one more step to complete COM support.
>
> Why not just use the COM variant struct?

Because you can't just assign a number or a string to it, nor you can do arithmetics with them, or pass them to functions expecting strict types etc

"Walter" <walter@digitalmars.com> wrote in message news:a3gh3a$1k44$3@digitaldaemon.com...

> That's what I meant by you lose all type checking with variants. Aside
from
> interfacing to COM, why use variants? When I've used them, there were
always

print() example above. Do you have any other idea of type-safe (unlike
printf)
way to do console I/O.

> unanswerable issues like what do you do when you add a float and a string?

    throw TypeMismatch;

> Then there was always the problem (I ran into with COM) of getting some nutball variant type back that you have no idea what to do with - like I expect a number, and I get a VT_DISPATCH. Or I want to pass a null type,
do


    throw TypeMismatch; // =)

> I do a VT_EMPTY or a VT_NULL? COM interfaces are full of lack of documentation about what variant types are allowed. Wierd crashes happen when the COM programmer forgot that he needs to deal with VT_R4. I guess I've just had bad experiences with variants.

Okay, then make your own implementation, not COM one.

> You can get close to that with the union initialization syntax.

For example?

Varints are an error waiting to happen.  Code reliability must trump silly convenience features.

If you need to return a string and an integer, return two variables.  It's as simple as that.

if return.flag = 0 then
   process string
else
   process flag
endif


Pavel Minayev <evilone@omen.ru> wrote in message news:a3g9cv$19bk$1@digitaldaemon.com...
> Walter, have you considered adding variants to the language?

"D" <s_nudds@hotmail.com> wrote in message news:a3lef2$no9$1@digitaldaemon.com...

> Varints are an error waiting to happen.  Code reliability must trump silly convenience features.

Don't like 'em - don't use 'em.
Also, variants are still better that printf() anarchy.

And what about multi-type arrays?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a3gmge$1m7q$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a3gh3a$1k44$3@digitaldaemon.com...
>
> > That's what I meant by you lose all type checking with variants. Aside
> from
> > interfacing to COM, why use variants? When I've used them, there were
> always
>
> print() example above. Do you have any other idea of type-safe (unlike
> printf)
> way to do console I/O.

Define a way to convert each type to a string. A string is what you want anyway for console I/O.


> > unanswerable issues like what do you do when you add a float and a
string?
>     throw TypeMismatch;

Unfortunately, that's not how COM works.

> > Then there was always the problem (I ran into with COM) of getting some nutball variant type back that you have no idea what to do with - like I expect a number, and I get a VT_DISPATCH. Or I want to pass a null type,
> do
>     throw TypeMismatch; // =)

Take all the VT_xx types in COM. Construct a matrix of the possibilities of 2 operand operations. Microsoft never defined what happens, so every COM implementor (including every Microsoft implementor) invented their own unique result matrix.


> > I do a VT_EMPTY or a VT_NULL? COM interfaces are full of lack of documentation about what variant types are allowed. Wierd crashes happen when the COM programmer forgot that he needs to deal with VT_R4. I guess I've just had bad experiences with variants.
> Okay, then make your own implementation, not COM one.

Then it really isn't that useful. Arggh.


> > You can get close to that with the union initialization syntax.
> For example?

You name which union member is the one you're initializing too.