On Thursday, 7 September 2017 at 19:33:01 UTC, apz28 wrote:
On Thursday, 7 September 2017 at 17:13:43 UTC, EntangledQuanta
wrote:
On Thursday, 7 September 2017 at 15:36:47 UTC, Jesse Phillips
wrote:
[...]
All types have a type ;) You specified in the above case that
m is an int by setting it to 4(I assume that is what var(4)
means). But the downside, at least on some level, all the
usable types must be know or the switch cannot be
generated(there is the default case which might be able to
solve the unknown type problem in some way).
[...]
Nice for simple types but fail for struct, array & object
Current variant implementation is lack of type-id to check for
above ones. For this lacking, is there a runtime (not compile
time - trait) to check if a type is a struct or array or object?
Cheer
On Thursday, 7 September 2017 at 19:33:01 UTC, apz28 wrote:
On Thursday, 7 September 2017 at 17:13:43 UTC, EntangledQuanta
wrote:
On Thursday, 7 September 2017 at 15:36:47 UTC, Jesse Phillips
wrote:
[...]
All types have a type ;) You specified in the above case that
m is an int by setting it to 4(I assume that is what var(4)
means). But the downside, at least on some level, all the
usable types must be know or the switch cannot be
generated(there is the default case which might be able to
solve the unknown type problem in some way).
[...]
Nice for simple types but fail for struct, array & object
Current variant implementation is lack of type-id to check for
above ones. For this lacking, is there a runtime (not compile
time - trait) to check if a type is a struct or array or object?
Cheer
No, it is not a big deal. One simply has to have a mapping, it
doesn't matter what kind of type, only that it exists at compile
time. It can be extended to be used with any specific type. One
will need to be able to include some type information in the
types that do not have them though, but that only costs a little
memory.
The point is not the exact method I used, which is just fodder,
but that if the compiler implemented such a feature, it would be
very clean. I left, obviously, a lot of details out that the
compiler would have to due. In the protoypes, you see that I
included an enum... the enum is what does the work... it contains
type information.
enum types
{
Class,
Float,
Int,
MySpecificClass,
}
the switch then can be used and as long as the actual values
'typeid' matches, it will link up with the template.
You can't use types directly, that would be pointless, they have
to be wrapped in a variant like type which contains the type
value. e.g.,
struct Variant(T)
{
types type;
T val;
alias this = val;
}
which is a lightweight wrapper around anything. This is basically
like std.variant.Variant except the type indicator comes from an
enum. Again, this simplifies the discussion but it is not a
problem for classes, structs, enums, or any other type, as long
as they exist at compile time.
I only used std.variant.Variant to simplify things, but the
compiler would have to construct the typeid list internally. (I
did it in my add explicitly for the types I was going to use)
As far as runtime checking, no, because bits are bits. You can
cast any pointer to any type you want and there is no way to know
if it is suppose to be valid or not. This is why you have to
include the type info somewhere for the object. classes have
classinfo but there would be no way to validate it 100%.
