# [.net] If you could request one feature for the next C# and/or .NET version, ...?

This topic is 3061 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

So, if you could add one feature to C# 5.0 and/or the .NET framework 5.0, what would it be? For example, in another thread, alot of people mentioned they wanted inline classes like Java has.

The one thing I currently miss is an access modifier for members of nested classes which give access only to the surrounding class.

For example, I would like a public nested class that the rest of the program could access, but with a constructor that is only visible to the surrounding class.

// What I wantpublic class Outer{    public class Inner    {        surrounding_only Inner(Outer outer)        {            // ...        }        // Some members here.. ..    }    public Inner GetInner()    {        return new Inner(this);    }   }// What I have to do nowpublic class Outer{    public class Inner    {        protected Inner(Outer outer)        {            // ..        }        // Some members here.. ..    }    class PrivInner : Inner    {        public PrivInner(Outer outer) : base(outer)        {}    }    public Inner GetInner()    {        return new PrivInner(this);    }}

This thread might be better off in the lounge, but since the question is so releated to .NET, I'm posting it here. A moderator can move it if he/she finds it necessary.

##### Share on other sites
Hmmm, propably property scoped fields.

class SomeClass{    public string Name    {        string _name;        get { return _name; }        set         {            if (value != _name)            {                 _name = value;                 OmgTheNameHasChanged();            }        }    }    public void SomeMethod()    {           _name = "blah"; // ERROR!!!        Name = "blah"; // ok!        // possibly allow direct access like this        Name._name = null;     }}

##### Share on other sites
Quote:
 propably property scoped fields

I'd like to have a NotifyPropertyChangedAttribute so I can finally get rid of backing fields all together:

[NotifyPropertyChanged]
public int Blah { get; private set; }

##### Share on other sites
Annonymous classes that can implement interfaces and aren't read-only (reusing optionally syntax for public/private get set without code from anonmyous properties).

##### Share on other sites
Quote:
 Original post by DvDmanDTThe one thing I currently miss is an access modifier for members of nested classes which give access only to the surrounding class.For example, I would like a public nested class that the rest of the program could access, but with a constructor that is only visible to the surrounding class. *** Source Snippet Removed ***

In this cases, you use the internal modifier. That kind of access looks tipical of library objects, so your end user is good anyway.

Quote:
 alot of people mentioned they wanted inline classes like Java has.

I suspect they're looking for lambda expressions, something Java has not (or has it, but just recently gotten?).

...I do have a wish list, but I have to think it thoroughly before spamming it on the intarwebs.

##### Share on other sites
* RAII
* multiple inheritance
* free functions
* type aliases and strong typedefs
* builtin copying and deep-copying semantics for objects
* C++ style const correctness
* lazy instantiation / non-constrained generics (possibly let compiler emit throw-statements for non-covered instantiation cases), this would eliminate a lot of workaround code
* non-type generics parameters
* [partial] specialization of generics

The latter three would mean that microsoft would have to introduce a typename and a generic keyword as in C++, or alternatively switch to another notation for generic argument lists like did D.

Btw, no, I am not doing .net in private life. Those things would improve my personal occupation productivity.

And this is a stylistic nitpick:

* multi declarator var

[Edited by - phresnel on July 2, 2010 3:06:10 AM]

##### Share on other sites
Discriminated Unions.

##### Share on other sites
Quote:
 Original post by phresnel*snip*

Just my view on your wishlist, I'm open to constructive discussion since it's a good way to learn different mindsets:

RAII: using blocks (where applicable) + IDisposable

mult. inheritance: .net favours composition over inheritance in this regard. can't say it's a bad thing. You may declare N interfaces, then delegate interface implementations to concrete types. More typing, you say? definitely. :)

free functions: static methods in static classes.

IMyDictionary : IDictionary<string, MyOtherType>
. applicable as long as you can derive from the original types.

built-in copying and deep copying: I think the way .net objects are laid out in memory makes them not suitable for blitting around (which is what happens with c++ objects? honest curiosity, not a c++ aficionado). in .net, it wouldn't be that efficient anyway.

non-type generic parameters: use-case example?

partial generic specialization: constraint to an interface type and write over the most general case; however, the lack of interfaces for integral types poses a problem to this (i.e. old problems and related workarounds about basic operators such as +,-,/,* for numerical types).

Quote:
 lazy instantiation / non-constrained generics (possibly let compiler emit throw-statements for non-covered instantiation cases), this would eliminate a lot of workaround code

To me, lazy instantiation means using something like Lazy<T>. But I think you mean something else here.

Clearly C++ / .net are two very different beasts, so idioms don't map 1:1 across environments. Expecting otherwise does no good to productivity with either tool.

But perhaps all of this belong to another thread. :P

##### Share on other sites
Quote:
Original post by Rainweaver
Quote:
 Original post by phresnel*snip*

Just my view on your wishlist, I'm open to constructive discussion since it's a good way to learn different mindsets:

RAII: using blocks (where applicable) + IDisposable

This is not the same. Think of having multiple resources -> nested using-statements. By default, it does the wrong thing, i.e. not dispose at the right moment. E.g. one of your function opens a file for writing and forgets to close it, one of the others opens it for reading, but will fail. In real-world scenarios this can be hard to detect, especially when chances for occurence of bugs are 1/100000000.

RAII is also a paradigm, you can trust in that the destructor will be called in any case at a specific place (in case of functions, it will be before returning). It's not really specific to resources.

Another thing is that destructors are guaranteed to run for every class object, you can rely on this. This not done with Disposables (btw, from real world, I had some applications running in production for months, before realising I got to manually dipose them).

Even with finally, things are not easy:

try {        Console.WriteLine("Foo");        throw new Exception();} finally {        Console.WriteLine("Bar");        throw new Exception();        Console.WriteLine("Frob");}

-> only "Foo" gets printed.

try {        Console.WriteLine("Foo");        throw new Exception();} catch {} finally {        Console.WriteLine("Bar");        throw new Exception();        Console.WriteLine("Frob");}

-> only "Foo" and "Bar" gets printed. "Frob" is still bad.

Quote:
 mult. inheritance: .net favours composition over inheritance in this regard. can't say it's a bad thing. You may declare N interfaces, then delegate interface implementations to concrete types. More typing, you say? definitely. :)

My point is mostly about mixin-based programming. Real life Use-case: I had a mixin that adds a static deserialization method and a non-static serialization method, so serialization became a half-liner. Problem: I could no longer derive from other classes. Workaround: Extension methods for serialization, static member functions for deserialization (intellisense farewell).

And in another use-case, I had to derive some class X from a another class that was needed for database-serialization (XPO). But I wanted class X to be identical to another class Y, except for the XPO thingy. I could have just derived X from Y and from that XPO thing, but my choices were:

• delegate everything, using composition

• extract an interface from Y, derive X from it, delegate everything, using composition

• extend the original class Y -> 0) not possible, because Y already derived from a class, and 1) this would have been intrusive because the library that contains Y is completely orthogonal

Now I had another 200LoC-class to maintain, where in programming language that allows for multiple inheritance it would have been a 20 liner.

Admittedly, this does not happen often, but when, it sucks and decreases productivity.

Quote:
 free functions: static methods in static classes.

My main pain with this is that I often have to introduce arbitrary names for enclosing classes, and that I cannot just write a function name but everything must be composed of X.Y. Extension methods are good, but imho, free functions are often better. And would have made my serialization thingy above way nicer too use (also, less code clutter at caller site).

Quote:
 strong typedefs: how about interfaces? IMyDictionary : IDictionary. applicable as long as you can derive from the original types.

strong typedefs are something I also wish for C++, as in D, which differentiates between aliases and real typedefs.

They are more sophisticated than interfaces; you already gave one of the reasons. Let me give an example for why I think they would be great:

strong_typedef float kph; // and be done, no accidental assignment of plain float or maybe lux to kph

or to make argument lists more typesafe

strong_typedef float Height;strong_typedef float Width;strong_typedef float Depth;Cube cube(Width w, Height h, Depth d) {    ...}int main () {    Cube = cube(Width(5), Height(3), Depth(2));}

Especially functions and ctor's with long argument lists could benefit. Admittedly, C# already has named arguments.

Quote:
 built-in copying and deep copying: I think the way .net objects are laid out in memory makes them not suitable for blitting around (which is what happens with c++ objects? honest curiosity, not a c++ aficionado). in .net, it wouldn't be that efficient anyway.

It is customary in C++ whether to pass a reference or value. Depending on how operator=() is implemented, there is top-level-copying or deep-copying. Personally, I would prefer to be able to forbid operator= all together, and then have a ref(), deep_copy()- and copy()-method in the passed value.

Quote:
 non-type generic parameters: use-case example?

This goes hand in hand with C++ style constness. E.g.

class Array<T, int N> {    T values[N];};class Cube {    Array<Plane, 6> faces.};

Basically, the same use-cases as in languages that allow for non-type arguments. Together with [partial] specialization, being able to write a compile time ray tracer and naming it generitrace would be a funny side effect :D

Another example, together with partial specialization: Expression templates, and being able to not use them for vectors below a profitable size.

Quote:
 partial generic specialization: constraint to an interface type and write over the most general case; however, the lack of interfaces for integral types poses a problem to this

E.g., you could have a generic class Frob<T>. It aggregates another generic, Foo<T>. Now if Foo<T> would have a specialization for T=x, than also every Frob<T> with T=x would benefit from it. Same of course for everyone else who uses Frob<> or Foo<>.

Quote:
Quote:
 lazy instantiation / non-constrained generics (possibly let compiler emit throw-statements for non-covered instantiation cases), this would eliminate a lot of workaround code

To me, lazy instantiation means using something like Lazy<T>. But I think you mean something else here.

This one.

Quote:
 Clearly C++ / .net are two very different beasts, so idioms don't map 1:1 across environments. Expecting otherwise does no good to productivity with either tool.

Absolutely true. But as the OP was about what I'd like to see, I stated that :)

Quote:
 But perhaps all of this belong to another thread. :P

As long as we don't flame each other, I think stating reasons is not bad :)

##### Share on other sites

hm nice one.. I am totally happy with C# as it is in VS2008.. so, only small things, such as..

I would like better support for structs and math operations. I hate to have to "new" a struct. This looks messy:

Vector3 v1=new Vector3(a,b,c);

Vector3 result=v1+new Vector(0,1,0);

Compared to a C++ equivalent:

Vector3 v1(a,b,c);

Vector3 result=v1+Vector3(0,1,0);

I find that "new" in the c# version to interrupt the flow when reading math expressions.
I would also like overloaded operators' operands to be passed by ref, again a-la C++.

1. 1
2. 2
Rutin
19
3. 3
khawk
18
4. 4
5. 5
A4L
11

• 9
• 12
• 16
• 26
• 10
• ### Forum Statistics

• Total Topics
633769
• Total Posts
3013755
×

## Important Information

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!