Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
February 04, 2002 simplifying variants | ||||
---|---|---|---|---|
| ||||
Okay, so I just thought and come to the idea that arithmetics on variants is not really needed, especially if they are "strict". One could always use typecasting: variant a, b, c; a = (int)b + (int)c; Now this means that variant is practically just a union with a type flag, something like this: struct variant { enum Type { Int, Float, Pointer, String, Object } Type type; union { int i; float f; void* p; char[] s; Object o; } } There are only two "special" cases that have to be handled by the compiler. First is typecasting, that should check variant.type and throw an exception when trying to cast to wrong type, and the second is that other types (int, extended, void*, char[], Object - exact list) should be implicitly convertable to variant. That's pretty much all really needed. Would it be hard to implement? |
February 04, 2002 Re: simplifying variants | ||||
---|---|---|---|---|
| ||||
Posted in reply to Pavel Minayev | BTW another idea about unions. Why not make it so that union is =impicitly= convertable to any of the types it consists of? union intstr { int i; char[] s } intstr x; ... toString(x); // same as toString(x.s); ... sin(x); // same as sin(x.i); If there are two members of the same type in the union, it cannot be implicitly casted to that type. If there are two or more possible casts, explicit typecast is needed: union Foo { int* a; float* b; } void bar(void*); ... Foo foo; bar(foo); // invalid bar(cast(int*) foo); // okay bar(cast(float*) foo); // also fine |
February 04, 2002 Re: simplifying variants | ||||
---|---|---|---|---|
| ||||
Posted in reply to Pavel Minayev | "Pavel Minayev" <evilone@omen.ru> wrote in message news:a3ms9o$1s2u$1@digitaldaemon.com... > enum Type { Int, Float, Pointer, String, Object } It'd better be: enum Type { None, Int, Float, Pointer, String, Object } "None" means that variant is not initialized, and is the default. Such a variant cannot be casted to any type. Just a safety feature, much like floats NaN. |
February 04, 2002 Re: simplifying variants | ||||
---|---|---|---|---|
| ||||
Posted in reply to Pavel Minayev | "Pavel Minayev" <evilone@omen.ru> wrote in message news:a3ms9o$1s2u$1@digitaldaemon.com... > enum Type { Int, Float, Pointer, String, Object } It'd better be: enum Type { None, Int, Float, Pointer, String, Object } "None" means that variant is not initialized, and is the default. Such a variant cannot be casted to any type. Just a safety feature, much like floats NaN. |
February 04, 2002 Re: simplifying variants | ||||
---|---|---|---|---|
| ||||
Posted in reply to Pavel Minayev | I might (not sure yet) be in favor of a "variant of" syntax: variantOf[int,bool,Object,Foo] MyFunc(); variantOf[int,bool,Object,Foo] var; var = MyFunc(); A variantOf[] would be a struct that includes a union of all of the types along with an enum that tells what type is currently being used. A variantOf[] could be implicitly cast to any of the underlying types. However, the compiler would check the enumerator at runtime and if the type was incorrect, it would throw an exception. A variantOf[] could be implicitly cast FROM any of the underlying types, and the compiler would, at runtime, set the enumerator properly. I understand that this would be a runtime performance hit, and I'm not sure I like the idea...but it's a possibility. -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ] |
Copyright © 1999-2021 by the D Language Foundation