Code Generation bug with Generics and bool

[hopscc]

This code

	s = Stack<of bool>()
	s.push(true)
	s.push(true)
	s.push(true)
			
	tf = false
	tf = s.pop to !  # ==> compile fail 

gives a compiler error from the c# compiler:
...Bug.cobra(7): error: "bool" does not contain a definition for "Value" (C#)
Compilation failed - 1 error.

This code gives a warning but seems to compile and run OK.

	s = Stack<of bool>()
	s.push(true)
	s.push(true)
	s.push(true)
			
	tf = false
	tf = s.pop to bool  # ==> warning   change to 'to !'
	assert tf==true	

Bug.cobra(7): warning: The given expression is already a "bool", but nilable. You can just use "to !".
Compilation succeeded - 1 warning

Doing the same using a tmp variable compiles and runs AOK:

	s = Stack<of bool>()
	s.push(true)
        s.push(true)
	s.push(true)

        tf = false
	b = s.pop
	tf = b to !
	assert tf==true	

So whats the beef

with the first version ?

[Chuck]

This is a bug at the intersection of nilable types, generics and DLLs. I thought another ticket mentioned this too, but I didn't find it at a glance.

When Cobra reads DLLs, it assumes that reference return types are nilable since .NET itself does not have non-nil enforcement on reference types. For example, Control.name is read as "pro name as String?".

This happens for generic types as well so Cobra sees Stack.pop as "def pop as T?". If you defined a MyStack class in your source, for example, you would not have this problem.

I also have this in my personal notes:

Stack.pop is interesting. Stack<of String>.pop should return "String" not "String?" because the inner type is not nilable. Does that mean that .pop should get the non-nil treatment? If it does, will Stack<of String?>.pop have the correct return type ("String?")? If so, should all generics get the non-nil treatment for their generic parameters due to the nilness being determined by the argument?

-- I'm upping the priority to "major".