The .NET Compiler Platform ("Roslyn") provides open-source C# and Visual Basic compilers with rich code analysis APIs.
- 'why not' is not a reason
You're saying this should be allowed, but I can't think of a reason why you would need it to be allowed
If you want it supported, make a compelling case for why
Again, nullable types:
Again, nullable types:
Hrmmm. That was supposed to be quoting you.
Again, I don't see the issue there. You are comparing different types.
Please open a proposal
@CyrusNajmabadi
Please open a proposal
I was pretty sure there is one already
@CyrusNajmabadi
- 'why not' is not a reason
Nullable is a type. I expect to be able to use it in any Type context. But for some reason I can't
When nullable struct is passed everyplace in compile time thinks it's underlying type but in runtime it's actually nullable (GetType() != typeof(T))
looks quite hacky
@CyrusNajmabadi
Again, I don't see the issue there. You are comparing different types.
If you mean the code snippet then its the type inferred by the compiler. It should be the same as the type of object unless it's upcasted to something, which is not the case
You constrained your type parameter. it's like saying "i want to be able to pass an IEnumerable to a T constrained to IList"
if you write
Foo<T>(T t); then you certainly can call it with Foo<int?>
then you are generally saying "i can accept any type here". but if you constrain you are specifically stating "i only want specific types"
When nullable struct is passed everyplace in compile time thinks it's underlying type but in runtime it's actually nullable (GetType() != typeof(T))
Yo have it backwards. At runtime it's the underlying type. i.e. say i do this:
int i1 = 1;
int? i2 = 1;
object oi1 = i1;
object oi2 = i2;
if you ask what the types of oi1 and oi2 are you'll get back 'System.Int32' in both cases
and that's correct
because that's what it is
there's no concept of a 'boxed nullable value type'
that would be totally unnecessary (and two layers of indirection)
the entire point of nullable value types is that they are the bridge here
if i2 was a 'null' nullable, it doesn't get wrapped witha non-null object (like other value types would). it literally becomes null.
try it out:
int i1 = 1;
int? i2 = 1;
int? i3 = null;
object oi1 = i1;
object oi2 = i2;
object oi3 = i3;
Console.WriteLine(oi1.GetType());
Console.WriteLine(oi2.GetType());
Console.WriteLine(oi3 == null);
This message was deleted
looks quite hacky
idisagree, it would be hacky otherwise
you'll see this with all sorts of scenarios. for example:
IList<int> list = new List<int>()
IsTypeofEqualsToGetType(list)
this will be false. because the runtime type of 'list' is List<int>, but the inferred type for T will be IList<int>
there isn't anything hacky about this, it's the normal way that runtime types (including boxed values) doesn't match the static declared type.
It should be the same as the type of object unless it's upcasted to something, which is not the case
i can find nothing in the spec (either C# or .Net) to indicate that that should be true
where are you getting that from?
it sounds like a fundamental misunderstanding of what types/values are, including what nullable types and their vlaues (boxed and unboxed) are.