Why does C# not support this?

I'm all for intelligent compilers. On the other hand, as mentioned

1) it doesn't work with type-inference because there's unsolvable ambiguity

2) it doesn't work in a "purely" side-effecting scenario where the result is forgotten (of course here the Command Query Separation principle will dictate that you do not do that anyway)

3) it doesn't work in a scenario involving inheritance where both return types inherit from the same base type and the variable is of that base type

Please, do not speak evil about type-inference - it is hugely more important than this non-feature which will only save you keystrokes in a very limited set of scenarios that could be solved by choosing a different name; type-inference is pervasively important, this feature not so. So where could this be used?

1) when assigning to an explicitly typed variable, field or property where there is no inheritance ambiguity

2) when the return value is used as part of a function call and there is no inheritance ambiguity

Still, it's hugely less important than type-inference which saves keystrokes everywhere without sacrificing type safety (intent is expressed on the right hand side of the assignment symbol).

W3bbo said:

vault said:

*snip*

That VB code fragment introduces an ambiguarity, variable "MyClass" with type "MyClass"; but I get your point.

 

I recognise that in cases where the implementation matters as much as the interface the "traditional way" of doing things could make way for some kind of succint syntax for instantiation, how about this:

 

SomeClass foo = new; // default constructor

SomeClass foo = new( /* constructor params go here */ );

That VB code fragment introduces an ambiguarity, variable "MyClass" with type "MyClass"

What's ambiguous about that? Sure, it might be confusing to read, but the VB compiler has no problems with it. Neither does the C# compiler for that matter.

Sven Groot said:

W3bbo said:

*snip*

What's ambiguous about that? Sure, it might be confusing to read, but the VB compiler has no problems with it. Neither does the C# compiler for that matter.

If the class MyClass has a static member Foo and an instance member Foo, then you've got an ambiguity.

W3bbo said:

Sven Groot said:

*snip*

If the class MyClass has a static member Foo and an instance member Foo, then you've got an ambiguity.

C# disallows having a static and instance members of the same name, I'm pretty sure.

Is VB the same?

You can't have two different return types because it would break polymorphism.

Although this has been beaten to death, I would like to add that there is no language in the world of which I am aware that supports this kind of a thing. Function overloading requires that argument parameters differ and implementing this would require a language in which side effects are non-extant.

That would require a language implementing this feature be either functional or imperative without any object oriented features. If you really want to do this, you could try forking C. You could even call it C--.

Shining Arcanine said:

Although this has been beaten to death, I would like to add that there is no language in the world of which I am aware that supports this kind of a thing. Function overloading requires that argument parameters differ and implementing this would require a language in which side effects are non-extant.

 

That would require a language implementing this feature be either functional or imperative without any object oriented features. If you really want to do this, you could try forking C. You could even call it C--.

C-- is a real language.

W3bbo said:

Shining Arcanine said:

*snip*

C-- is a real language.

I had no idea that the name had been taken. I guess he could call it D-- then.

Ion Todirel said:

Shining Arcanine said:

*snip*

or B++

Just don't name-collide with B or the B-Method

Shining Arcanine said:

W3bbo said:

*snip*

I had no idea that the name had been taken. I guess he could call it D-- then.

D-flat is the same music note as C# right?

That's what the freetards call c# in the forums anyway.

Maddus Mattus said:

Shining Arcanine said:

*snip*

D-flat is the same music note as C# right?

 

That's what the freetards call c# in the forums anyway.

 

To be completely accurate, C♯ and D♭are enharmonic equivalents (the same tone but written differently), but only in the modern twelve-tone equal temperament tuning system.

I believe the CLR actually does support this, but C# does not in the general sense except in the context of conversion operator methods.

Sven Groot said:

Maddus Mattus said:

*snip*

To be completely accurate, C♯ and D♭are enharmonic equivalents (the same tone but written differently), but only in the modern twelve-tone equal temperament tuning system.

 

 

I never thought I'd see something that uses my BA in Music on a computer programming forum.

Sven Groot said:

Maddus Mattus said:

*snip*

To be completely accurate, C♯ and D♭are enharmonic equivalents (the same tone but written differently), but only in the modern twelve-tone equal temperament tuning system.

 

 

That's why you never go and learn pentatonic and still pretend to be a sane man

(note: not to be confused with Miskatonic. That's a university)

andokai said:

I believe the CLR actually does support this, but C# does not in the general sense except in the context of conversion operator methods.

So, I am so hardcore c# doesnt understand me, but the compiler does?