Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 02:52
    jnm2 commented #40259
  • 02:43
    mavasani edited #40289
  • 02:43
    mavasani review_requested #40289
  • 02:43
    mavasani review_requested #40289
  • 02:43
    mavasani opened #40289
  • 02:13
    jcouv assigned #40033
  • 02:13
    jcouv commented #40033
  • 02:11
    mareklinka commented #40033
  • 02:10
    jcouv labeled #40266
  • 02:10
    jcouv labeled #40112
  • 02:10
    jcouv labeled #40052
  • 02:10
    jcouv labeled #40051
  • 02:10
    jcouv labeled #39981
  • 02:10
    jcouv labeled #39122
  • 02:10
    jcouv labeled #39094
  • 02:09
    jcouv labeled #38270
  • 02:09
    jcouv labeled #36946
  • 02:09
    jcouv labeled #36550
  • 02:07
    jcouv commented #40033
  • 02:07
    tmat edited #40287
Psilon
@Pzixel
I wish I had that for C# as well. It's great, showing intermediate representation, assembly, supporting usings, debug/release modes, etc etc. </offtopic>
jp2masa
@jp2masa
HaloFour
@HaloFour
Yeah, that works pretty well. Also lets you switch between Roslyn branches to play with new features, but YMMV with that
CyrusNajmabadi
@CyrusNajmabadi
Because why not? I can pass Foo<int>, why couldn't I Pass Nullable<int>?
  1. '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.
CyrusNajmabadi
@CyrusNajmabadi
And I think it's valuable to have this in C#
Please open a proposal
Amadeusz Sadowski
@amis92
@Pzixel you mean like that? https://sharplab.io/
Johan Larsson
@JohanLarsson
is gitter extra broken?
Yair Halberstadt
@YairHalberstadt
Seems to be to me @JohanLarsson
Psilon
@Pzixel
@amis92 yeah, I found it not so long ago and it's wonderful. I wish it get better )

@CyrusNajmabadi

Please open a proposal

I was pretty sure there is one already

@CyrusNajmabadi

  1. '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

CyrusNajmabadi
@CyrusNajmabadi
Nullable is a type. I expect to be able to use it in any Type context. But for some reason I can't
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);
CyrusNajmabadi
@CyrusNajmabadi
this is the same in reverse, a null object can always become a nullable value type (i.e. the null value of it)
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.
CyrusNajmabadi
@CyrusNajmabadi
it's worth doing the mental exercise to imagine if it were different