Question: Does specialization of none|@T works as intended?

[dumblob]

0$ dao -e 'routine return_some_complicated_non_none_type() { 1 }; x: none|@T = none; x = return_some_complicated_non_none_type(); if (x == none) io.writeln("A", x) else io.writeln("B", x)'
[[ERROR]] in file "command line codes":
  At line 0 : Invalid function definition --- " __main__() ";
  At line 1 : Invalid virtual machine instruction --- " MOVE:3,1,1 ";
In code snippet:
      3 :  CALL        :     2 , 32768 ,     3 ;     1;   return_un...()
>>    4 :  MOVE        :     3 ,     1 ,     1 ;     1;   x = return_un...
      5 :  GETCG       :     0 ,     1 ,     4 ;     1;   none
  At line 1 : Invalid operation on the type --- " x = return_unknow... ";
  At line 1 : Types not matching --- " 'int' for 'none' ";

After changing @T to any, it starts working fine.

[Night-walker]

@T is meant to be a placeholder for type; declaring a variable with @T in its type makes no sense for me, I don't think it should be allowed unless there is some actual @T in this context resolved to a known type.

[dumblob]

unless there is some actual @T in this context resolved to a known type.

Exactly - it's known at compile time, but not at the place of declaration. I thought, that the resulting type is derived from the first non-none occurence of assignment in the subsequent use of the none|@T variable. In other words, @T placeholder would serve as a temporary type being filled in later (this should be pretty much the general semantics of type holders in Dao if I'm not mistaken).

[daokoder]

@T is meant to be a placeholder for type; declaring a variable with @T in its type makes no sense for me, I don't think it should be allowed unless there is some actual @T in this context resolved to a known type.

For x: none|@T = none, the expression in the right side of the assignment actually provides a context to resolve the type holder. But in this case, the type holder cannot be resolved, because here none will match to none, ignoring the type holder.

[daokoder]

Exactly - it's known at compile time, but not at the place of declaration. I thought, that the resulting type is derived from the first non-none occurence of assignment in the subsequent use of the none|@T variable. In other words, @T placeholder would serve as a temporary type being filled in later (this should be pretty much the general semantics of type holders in Dao if I'm not mistaken).

It has to be known at the place of declaration.

[daokoder]

Fixed. Now x is left as unspecialized type none|@T, which allows the second assignment to succeed.

[dumblob]

It has to be known at the place of declaration.

And that's quite inconvenient - none is the best fit for a "special value" in case one can't or doesn't want to use some "stop" value.

Fixed. Now x is left as unspecialized type none|@T, which allows the second assignment to succeed.

Great. This was just my assumption not based on thorough thinking.

By the way, I was already several times thinking about some way how to "extract" type information from a function or variable and use this type as any other manually written type. E.g. something like x: none|@<T=return_some_complicated_non_none_type> = none. This should make things clear, concise and allow easy manipulation without the need of having the not-so-obvious "second assingment rule".