December 06, 2012
On Thursday, December 06, 2012 01:06:33 Dmitry Olshansky wrote:
> > To know what on earth you're suposed to do with the variable. If it's a type that you can't handle, then yes, you'd probably have to throw an exception, but you generally use a Variant because you need to be able to return multiple types from the same function, and each is going to be treated differently, otherwise you could have just used a common type to begin with.
> 
> This is a sort of case against Varaint at large.

Honestly, the only use cases for Variant that I would consider valid would be those where you _can't_ use static typing in any sane way - the places where you're effectively forced to use a union (where a Variant is a better union). If you can reasonably solve the problem by using a common type, then I'm completely against using Variant for it.

Pretty much the only kind of situation that I remember running into where I would consider Variant to be a good solution is one where you literally have to return a type from a function where you can't know that type at compile time, and there is no common type to use. And the only time that I recall running into that recently was in writing a lexer (the values of literals ended up having to be put in a variant type). There are obviously other use cases besides that (database-related stuff and spreadsheets like you mentioned are other possibilities), but they are extremely rare in my experience. In almost all cases, you can and should know the type at compile time, in which case, using Variant makes no sense.

- Jonathan M Davis
December 06, 2012
On Wednesday, 5 December 2012 at 19:32:03 UTC, Jonathan M Davis wrote:
> Yes, but that inevitably forces you to check the type in order to handle it correctly, which means that implicit conversion just doesn't work. In order for implicit conversion to work, you have to be able to assume that you're dealing with a particular type, and if you can do that, why are you using a Variant in the first place? Just use a common type.

 I know for my own project a common type isn't possible (It's a block of raw memory most of the time), but i do know at certain points if it's one type or another just because of where it's at. In order to handle all the types it ends up either being a pointer (union for all) or use long and double and string, but you I have to call them manually (geti, gets, getf).

 Also implicit conversion only makes sense if it's a type that can be converted to. Any user type can't be converted without alias this or classes/interfaces.
December 10, 2012
On Thursday, 6 December 2012 at 00:31:53 UTC, Jonathan M Davis wrote:

> Pretty much the only kind of situation that I remember running into where I
> would consider Variant to be a good solution is one where you literally have
> to return a type from a function where you can't know that type at compile
> time, and there is no common type to use. And the only time that I recall
> running into that recently was in writing a lexer (the values of literals
> ended up having to be put in a variant type). There are obviously other use
> cases besides that (database-related stuff and spreadsheets like you mentioned
> are other possibilities), but they are extremely rare in my experience. In
> almost all cases, you can and should know the type at compile time, in which
> case, using Variant makes no sense.
>
> - Jonathan M Davis

My experience with Variant has come from integration in LuaD (Probably like what I'd want from JSON).

My main use has been an Algebraic type of string, string[], and string[][string]. (Lua does not have arrays or dictionaries, it has a table).

In general when I request data I know which of these it is, however I do have some generic code to operate on any of these types, thus:

    if(myVar.peek!(string[][string]))
        ... myVar.get!(string[][string])

Does get repetitive and messy to read.

On another note, it is sad I can't have that defined as MyType[MyType].
1 2 3
Next ›   Last »