C:

function and operator overloading would be nice (ideally if it could be done in a mostly ABI transparent manner, *1);

MSVC fully supporting C99 would also be nice;

a precompiled header system that doesn't suck;

if va_list didn't suck as bad;

some sort of variant type (though can be emulated via overloaded operators);

ability to support late-bound functions (*2);

portable lambdas / anonymous functions (vs compiler-specific extensions);

ability to fully overload function-calling and field-lookup operations (*3, ?);

maybe keywords to more finely control some compiler behaviors (whether or not to unroll loops);

more usable and portable support for SIMD operations;

maybe(?) standard support for computed goto and inter-procedural goto;

maybe(?) break and continue with labels;

context and declaration-order independent parsing (like in C#, *4);

loading code at runtime from source (without 3rd party libraries or implementing it oneself, ...);

...

*1: I am sometimes left wishing for ability to use a few C++ features without having to, well, actually use C++.

though, yes, one can use a C-like subset of C++, there are "little details".

well, and the cultural issue:

if you use C, it is generally accepted that you will be doing all sorts of wackiness;

if you use C++ and don't use very specific "idiomatic" practices, then a lot of people start raging and freaking out.

person A writes "const char *str", person B "NOOOO! use 'const std::string &str'!".

but, yeah, "just use C++" is an option for a lot of this.

*2: usually can be emulated with wrappers.

though, passable would be if the wrapper could be written more compactly, ex:

int (*SomeFunction)(int, int) = ^(int x, int y)->int { return (SomeFunction=myAppGetProcAddress("SomeFunction"))(x, y); };

or:

int (*SomeFunction)(int x, int y) =>

(SomeFunction=myAppGetProcAddress("SomeFunction"))(x, y);

as-is, it either requires the creation of multi-part declarations, or a function which invariably requires an extra call-frame and an internal if-branch.

*3: basically, taking operator-overloading slightly further, and allowing creation of fully custom synthetic object types (IOW: where, for example, it would be possible to create ones own types of classes and their own types of function-handles in-language).

making this useful would go into crazy land WRT the language semantics though.

it is unclear if the semantics and complexity this would introduce would be worth the possible gains though (and would likely share some overlap with C++ templates).

*4: can be done within C by adding some language constraints, however, adding these constraints would itself violate the standard (by potentially rejecting otherwise valid code). however, in practice, the constructs which would violate these constraints are rather uncommon (this strategy has been used effectively with some of my code-processing tools).

some of this was considered for a never-implemented language I had called "C-Aux", which would have been essentially like a C99 / C# hybrid (with some C++ like elements glued on, ...) with some emphasis on remaining (mostly) source-compatible with C (and would probably run on my existing VM, though this was intermixed with thoughts related to the possibility of a newer/more-efficient VM backend, which has also largely gone nowhere, ...).

or such...

Isnt MSVC for c++?

it does both C and C++...

it also does C# and similar as well, ...

the main drawback of MSVC is that the version of C it supports is a little bit old / stale (MS hasn't exactly been big on implementing support for newer versions of the C standard).

now, as for language differences (between C and a C-like subset of C++):

the most obvious up-front issue is that by default C++ uses name-mangling, but there aren't really any solid ABI conventions for C++ name mangling, so pretty much each compiler does their own;

there are also differences in the behavior of pointers, for example, in C, 'void *' has traditionally been an "any type", where types can freely convert to/from 'void *', whereas in C++, the compiler will complain unless a cast is used, also differences as to whether things like int->pointer conversions will generate a warning, ...;

...

a more subtle difference has to do with OS headers:

with plain C, the preprocessor output mostly contains straight C stuff, with occasional compiler-specific stuff (and a lot of general wackiness);

with C++, often for the same headers, a bunch of C++ stuff will be dumped into the PP-output as well.

this means essentially for a code-processing tool, if it claims to be C++ when it parses various OS headers, then it also needs to be able to deal with things like namespaces and templates, ...

otherwise, to use a C++ subset means that the main native compiler may know it is C++, but for the tools it has to not be C++ (it tells the headers/... that it is C, but then internally uses a special define internally to detect C++ ness). however, in this case, generally all the usual 'extern "C"{ ... }' magic is absent, so it has to be assumed that pretty much everything uses the C ABI (or, the reverse case is true: now we need to explicitly flag sections which use the C++ ABI).

a lot of this can be wrapped in macros though, with the macros generating different output depending on whether the code is being parsed by the native-compiler or by the tools (this is already used for things like special declaration modifiers, ..., which may give special information to the tools but are omitted for the native compiler).

the specifics of which exact features are supported by tools is a bit tool-specific though.

In C# what I would like are the following:

- The ability to use ref / out on properties.

- Have a {get; readonly set;} so that the set is treated as a readonly field where it can be used in the constructor only so that I can have my readonly functionality in {get;} properties I inherit from interface properties.

- Have comments inherited so that I don't have to copy paste comments all the time as currently depending on what you are calling the comments may not even show, like say you have summaries in interfaces, the class that inherits interfaces would still need the same comments copy pastes

That truly is all I ask for

C#:

I have an irrational hatred of the "var" keyword. This is more of a style thing as it has its uses, but I've worked with people that use it everywhere.

++

I stand on the exact oposite side of the fence here, i strictly only use it as it pretty much never brings anything useful (most of the time, if it does, your variable uses a crappy name). You can only use it locally (not for members) and if a local member's use and functionality isn't immediately obvious then you're either using crappy names, or making huge functions, both of which are problems. Also most of the time this is needless repetition as the other side of the expression is new thetype() anyway.

Oh and as for what i'd like removed :

1) All the legacy crap! I just wish they had the guts to push forward and say "this is legacy, it's getting droped .net 5.0 and if you aint happy, stick to 4.5" on a lot of features to cut off large chunks of .net that were replaced by newer API (remove winform, keep WPF, remove remoting keep wcf etc) as well as legacy language décisions (none i can think of on the spot, but plenty on eric lippert's blog if you're curious). Also remove arraylist and rewrite everything that was written pre-generics. I would love all that!

2) .Net client profile : why? just why!!! Seriously it's a feature i never understood, in today's time is it really worth it to make a whole subset of .net for a measly 50mb download gain per client and push the need to make sure they understand your program requires .net, but not the .net they downloaded, another one with the same version number? Is the tiny insignificant benefit of halving (not dividing by 20 which i would understand since it would make it downloadable for people for whom it may not currently be 56K and all in some part of the world) Worth all the increased maintenance on their side and support on end devs side?

3) VB . net (nothing against it, but since now there is feature parity with C# i really don't get the point, you got the VB devs migrated, the job is done, finish the hoax and save up on the dev costs and put the VB compiler team guys on C# for more features / year instead of 2X same features / year). I'm saying VB because C# has always been the sprearhead language of .net but hell, if it was C# getting droped i could live with it (i doubt it would go well in the community, but i don't do double standards so "i" would be fine with switching to VB even though i don't like the syntax)

Well, despite all the small quirks the language has, my biggest beef against JavaScript is the lack of a (good) free editing tool. I've been jumping back and forth between Notepad++, Scripted and Brackets, but it amazes me to no end how no tool manages to implement a good code assist like WebStorm's.. But I currently can't afford it, so..

You might want to check out LightTable

It does indeed look interesting, but after messing with it for a while I can't make it do what I thought it would be able to do. I'm still getting better code hinting from Scripted or even Notepad++ than from LightTbale :/

Edit: it turns out, Brackets.io has been greatly improved since last time I tried it! And currently, if you add some plugins it does everything I missed from other editors. For anyone stumbling upon this post, I'm using these plugins: Beautify, Brackets Language Switcher, CSSLint, Indent Guides, Interactive Linter, Match Highlighter, PHPLint for Brackets, Select Lines, Simple JS Code Hints and WD Minimap.

- The ability to use ref / out on properties.

That would require changing how ref/ out works in msil. Currently ref/out works like a pointer in C++ (oversimplification, but broadly true). If you were allowed use properties, it would have to be a get/set method pairing instead.

Besides, you can already do

void Method(ref string s)
{...}

// ....
var f = new Foo
{
   Bar = "blah"
}

string bar = f.Bar;
Method(bar);
F.Bar = bar;

Yeah, it's slightly longer, but it's much more intention revealing.

- Have a {get; readonly set;} so that the set is treated as a readonly field where it can be used in the constructor only so that I can have my readonly functionality in {get;} properties I inherit from interface properties.

Amen, brother. This would be really useful.

- Have comments inherited so that I don't have to copy paste comments all the time as currently depending on what you are calling the comments may not even show, like say you have summaries in interfaces, the class that inherits interfaces would still need the same comments copy pastes

Seems like more of an IDE feature than a language feature.

Personally, I'd like to see the ability to define constructor signatures in Interfaces and Constraints.

Example:

interface IDBConnection
{
}

class DBConnection : IDBConnection
{
}

interface IQuery<TEntity>
{
   new(IDBConnection); // query always needs a connection object
   TEntity FindById(int id);
}

class Thing {}

class ThingQuery : IQuery<Thing>
{
   public ThingQuery(IDBConnection connection) {}
   
   // can have other constructors as well

   public Thing FindById(int id) 
   {
      //...
   }
}

public TEntity LookUpEntity<TEntity, TQuery>(int id, IDBConnection connection)
    where TQuery : IQuery<TEntity>
{
   var query = new TQuery(connection);

   return query.FindById(id); 
}

What I'd really like from C#: the ability to specify operator constraints. It's currently only possible by defining an interface with Add(), Multiply(), etc.. methods which is horrible as a) they must be non-static (so you can't even enforce that they are pure and generally behave like operators) and b) they incur some virtual call overhead and c) you can't use operators on the constrained types, which makes the resulting code look very ugly. In fact, adding some template-like features to generics would be pretty awesome, but I guess that won't happen any time soon.

I want the ability to define fixed size arrays not backed up by an actual container (i.e. just a raw array of objects with a constant length), the current "fixed" keyword which enables this sucks and requires going unsafe. I mean, how hard can it be? If anything the runtime could convert it into objects a, b, c, ... and pick the correct one depending on the index. I would even be fine with restricting the index to values the compiler can predict, as usually you just need them in a tight for loop rather than arbitrary access.

I also want the ability to request a struct to be aligned to an arbitrary memory boundary. We have StructLayout, surely it can't be that hard, and it would help a ton when doing interop with libraries with hard memory alignment requirements, currently you need to overallocate unmanaged memory yourself and locate a suitable boundary via pointers. And while we're at it, make a built-in size_t equivalent, (U)IntPtr doesn't cut it since while you can technically do limited arithmetic on it, it requires a cast to and from ordinal types as it's technically the abstraction of a pointer, which is inconvenient and somewhat awkward.

A standard arbitrary precision real number class would also be nice to have to go with the BigInteger. I hear there was one (BigFloat) but it didn't make it into the framework for some reason. Not really a language request but C# is also defined by and large by the .NET framework without which it would not be very useful.

Named tuples like in Python would be neat too, though I'm not too sure how they could be implemented in an elegant way within the current feature set the language offers. Item1 and Item2 are not particularly descriptive, though they beat writing yet another custom struct to handle it unless you're really using the same tuple type everywhere.

Have a {get; readonly set;} so that the set is treated as a readonly field where it can be used in the constructor only so that I can have my readonly functionality in {get;} properties I inherit from interface properties.

+1, it would also cut down on verbosity when defining immutable structs if this is made to work as an autogenerated property as well, so you can use the property instead of having a readonly backing field with no clear purpose other than taking up space. So tedious.

That would require changing how ref/ out works in msil. Currently ref/out works like a pointer in C++ (oversimplification, but broadly true). If you were allowed use properties, it would have to be a get/set method pairing instead.

It could still be done automatically by the compiler, i.e. "ref property" is turned into a sequence of reading the property into a variable, passing that in the ref argument and then assigning the result back to the property. For "out" you don't even need to read it. Only works if the property is settable (and gettable in the case of ref) of course. It doesn't look like it would cause any problems and would still be consistent with both property and ref/out semantics, and no need to change the JIT, it's just a quick preprocessing pass before compiling down to IL. I'm sure there's a good reason they didn't do that though, since it seems so obvious.

What I'd really like from C#: the ability to specify operator constraints. It's currently only possible by defining an interface with Add(), Multiply(), etc.. methods which is horrible as a) they must be non-static (so you can't even enforce that they are pure and generally behave like operators) and b) they incur some virtual call overhead and c) you can't use operators on the constrained types, which makes the resulting code look very ugly. In fact, adding some template-like features to generics would be pretty awesome, but I guess that won't happen any time soon.

I've lost count of the number of times I've wished for this.

A standard arbitrary precision real number class would also be nice to have to go with the BigInteger. I hear there was one (BigFloat) but it didn't make it into the framework for some reason. Not really a language request but C# is also defined by and large by the .NET framework without which it would not be very useful.

I'm still confused as to why they System.Decimal isn't fixed point in the first place. C# is largely targeted at business/enterprise and correct monetary calculations are in general more important than speed for this kinda thing. Besides, in your typical LOB app, the numeric calculations are rarely the bottleneck.

Named tuples like in Python would be neat too, though I'm not too sure how they could be implemented in an elegant way within the current feature set the language offers. Item1 and Item2 are not particularly descriptive, though they beat writing yet another custom struct to handle it unless you're really using the same tuple type everywhere.

Could you not use an anonymous type for the same thing? i.e.

var data = (from t in myThingList
            select new
            {  
                FirstNamedProperty = t.Something,
                SecondNamedProperty = t.SomethingElse,
            })

foreach (var datum in data)
{
   Console.Write(datum.FirstNamedProperty);
}