public class Worker { 
public int DoWork() { return 10; } 
public string DoWork() { return "Work"; } 
} 
public class Program 
{ 
public Program() 
{ 
Worker worker = new Worker; 
int workInt = worker.DoWork(); 
string workString = worker.DoWork(); 
}} 

 I know I know

But in 2010 a compiler should be intelligent enough, right?

Maybe I should put this in the c# 5.0 wishlist.

var whatAmI = worker.DoWork();

Do? and of course what would:

worker.DoWork();

Do when we don't care about the return?

I also don't like it because it doesn't seem properly polymorphic to me, as the return type is clearly related to what the function does, and now the identically named functions are clearly doing something different. But that's just me.

Massif said:

Well what would

 

var whatAmI = worker.DoWork();

 

Do? and of course what would:

 

worker.DoWork();

 

Do when we don't care about the return?

 

I also don't like it because it doesn't seem properly polymorphic to me, as the return type is clearly related to what the function does, and now the identically named functions are clearly doing something different. But that's just me.

I hate var's

they are for lazy programmers

and worker.DoWork() would not be possible, because DoWork has a return type. Ignoring the return is not 'first class' as Erik would call it

Maddus Mattus said:

Massif said:

*snip*

I hate var's

 

they are for lazy programmers

 

and worker.DoWork() would not be possible, because DoWork has a return type. Ignoring the return is not 'first class' as Erik would call it

Or of course:

ojbect thing = worker.DoWork();

And, if you have a class A which inherits from B which inherits from C (and DoWork implementations returning As and Bs) what does:

C wtf = worker.DoWork();

Resolve as? It'd just be too confusing for us humble programmers.

And I'm not letting you take away my god-given right to ignore return values!

Maddus Mattus said:

Massif said:

*snip*

I hate var's

 

they are for lazy programmers

 

and worker.DoWork() would not be possible, because DoWork has a return type. Ignoring the return is not 'first class' as Erik would call it

Today, worker.DoWork() is valid. You don't have to care that there's a return type. In a theoretical world, you can't make it always required that you capture the return value as that would be a breaking change. You could make it required only when there's such "overloads", but that's probably not a good idea as it introduces some tricky versioning scenarios. And that's all ignoring the very valid points that Massif has made. You may not like 'var', but it exists. There's also the issue with base types causing ambiguity. Technically, none of this prevents the introduction of overloading based on return type, as it's really no different from overloading based on out parameters, but it certainly seems like it would be much more confusing for developers and maintainers. I don't think it's a good idea.

Massif said:

Maddus Mattus said:

*snip*

Or of course:

 

ojbect thing = worker.DoWork();

 

And, if you have a class A which inherits from B which inherits from C (and DoWork implementations returning As and Bs) what does:

 

C wtf = worker.DoWork();

 

Resolve as? It'd just be too confusing for us humble programmers.

 

And I'm not letting you take away my god-given right to ignore return values!

I'm going to talk to god (Erik) about that!

Object should become a forbidden word, you can only inherit from object.

let's say we have A that inherits from B

if we have two methods:

A DoWork() and B DoWork()

A a = worker.DoWork() would result in using A DoWork(), if you want to use the B one use B b = worker.DoWork(), you lazy git

I've programmed for 6+ years now and I've never run into these problems before. Until recently,... But anyway,.. I've just attached a bool to the end of the parameters B DoWork(bool thisisherebecauseprogramlanguagesarestupid);

Maddus Mattus said:

Massif said:

*snip*

I'm going to talk to god (Erik) about that!

 

Object should become a forbidden word, you can only inherit from object.

 

let's say we have A that inherits from B

 

if we have two methods:

 

A DoWork() and B DoWork()

 

A a = worker.DoWork() would result in using A DoWork(), if you want to use the B one use B b = worker.DoWork(), you lazy git

 

I've programmed for 6+ years now and I've never run into these problems before. Until recently,... But anyway,.. I've just attached a bool to the end of the parameters B DoWork(bool thisisherebecauseprogramlanguagesarestupid);

Maddus

But there's a legit reason to do BaseClass b = DoWork();

It's not that what you propose isn't technically possible by the compiler, it just breaks OOP. You don't want the compiler to break OOP do you?

It would mean you'd need to have a "target type" for an expression in order to resolve which overload to use. That's OK in a trivial example such as yours where you can take it from the LHS of the assignment, but what about when you are evaluating a subexpression with overloads based on return type and that subexpression is passed as a parameter to function for which there are multiple overloads - which do you chose then?

Minh said:

Maddus Mattus said:

*snip*

Maddus

 

But there's a legit reason to do BaseClass b = DoWork();

 

It's not that what you propose isn't technically possible by the compiler, it just breaks OOP. You don't want the compiler to break OOP do you?

To make an omelet, you have to break some eggs

You could do something like

default A doWork()

B doWork()

C doWork()

D doWork()

would be cool!

Go do some work

Maddus Mattus said:

Minh said:

*snip*

To make an omelet, you have to break some eggs

 

You could do something like

default A doWork()

B doWork()

C doWork()

D doWork()

 

would be cool!

 

Go do some work

What if I had this really common scenario?

class Chicken { }

class Hen : Chicken { }

class Rooster : Chicken { }

List<Chicken> roster = new List<Chicken>();

roster.Add(DoWork());

Minh said:

Maddus Mattus said:

*snip*

What if I had this really common scenario?

 

class Chicken { }

class Hen : Chicken { }

class Rooster : Chicken { }

 

List<Chicken> roster = new List<Chicken>();

 

roster.Add(DoWork());

 

That was going to be my next question

And for all that breakage and confusion, what does it get you really?

That's why I don't think this should be implemented.

Maddus Mattus said:

Massif said:

*snip*

I hate var's

 

they are for lazy programmers

 

and worker.DoWork() would not be possible, because DoWork has a return type. Ignoring the return is not 'first class' as Erik would call it

I used to think so too, but after programming in Visual Basic properly, less is more.

In C# you have

MyClass myClass = new MyClass

Whereas in VB you have

Dim MyClass = As New MyClass

which is elegant, notwithstanding the 'Dim' keyword of course - what a tragedy

var myClass = new MyClass

results in far less code, and is infinitely more readable in the long run, especially with long namespaces and properly formatted Linq queries. 

vault said:

Maddus Mattus said:

*snip*

I used to think so too, but after programming in Visual Basic properly, less is more.

 

In C# you have

 

MyClass myClass = new MyClass

 

Whereas in VB you have

 

Dim MyClass = As New MyClass

 

which is elegant, notwithstanding the 'Dim' keyword of course - what a tragedy

 

var myClass = new MyClass

 

results in far less code, and is infinitely more readable in the long run, especially with long namespaces and properly formatted Linq queries. 

Oops, wrongemail address

MyClass myClass = new MyClass

Dim MyClass = As New MyClass

var myClass = new MyClass

vault said:

Maddus Mattus said:

*snip*

I used to think so too, but after programming in Visual Basic properly, less is more.

 

In C# you have

 

MyClass myClass = new MyClass

 

Whereas in VB you have

 

Dim MyClass = As New MyClass

 

which is elegant, notwithstanding the 'Dim' keyword of course - what a tragedy

 

var myClass = new MyClass

 

results in far less code, and is infinitely more readable in the long run, especially with long namespaces and properly formatted Linq queries. 

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 */ );

Massif said:

Minh said:

*snip*

That was going to be my next question

 

And for all that breakage and confusion, what does it get you really?

That I can do this:

FinanceResult<FinanceItem> GetActuals();

FinanceResult<FinanceItem, Dimension1, Dimension2> GetActuals();

But I guess I should do:

FinanceResult<FinanceItem> GetActuals();

FinanceResult<FinanceItem, Dimension1, Dimension2> GetActuals<Dimension1, Dimension2>();

Boring

Maddus Mattus said:

Massif said:

*snip*

That I can do this:

 

FinanceResult<FinanceItem> GetActuals();

FinanceResult<FinanceItem, Dimension1, Dimension2> GetActuals();

 

But I guess I should do:

 

FinanceResult<FinanceItem> GetActuals();

FinanceResult<FinanceItem, Dimension1, Dimension2> GetActuals<Dimension1, Dimension2>();

 

Boring

Gosh, the right way to do it:

public interface FinanceService // Just for grouping

{

    FinanceResult<FinanceItem> GetActuals();

    FinanceResult<FinanceItem, Dimension1, Dimension2> GetActualsWithDimension();

}

Ion Todirel said:

Maddus Mattus said:

*snip*

Gosh, the right way to do it:

 

public interface FinanceService // Just for grouping

{

    FinanceResult<FinanceItem> GetActuals();

    FinanceResult<FinanceItem, Dimension1, Dimension2> GetActualsWithDimension();

}

w00t thanks

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?

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.

Shining Arcanine said:

W3bbo said:

*snip*

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

or B++

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.

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?