If you could make breaking changes to C#, what would you do?
-
case 2: perform2stuff(); /* I think C# will complain here about not having a break...? */ goto case 3; case 3: perform2and3stuff(); /* C# will not execute this for 2, but C will. */ break;
-
@magus said in If you could make breaking changes to C#, what would you do?:
@cheong No.
Making namespaces follow directory structure is stupid anyway, and an awful default.
When you're calling things, you don't want to have 10 different usings for three different classes. You need an exception? Most of them are just in
System
.Large, flat namespaces are legitimately useful, while namespaces on a granular level only help if your architecture is over-engineered and repetitive.
No, that scheme is what I want, and what all projects that I create used.
The more classes in the "visible scope" of the class your working on, the longer compile time needed to resolve them, and the less responsive your IDE would be when with Intellisense enabled. (If all your classes are put on global namespace and you've never experienced that problem, you've not been working on big enough projects)
-
@cheong said in If you could make breaking changes to C#, what would you do?:
@djls45 said in If you could make breaking changes to C#, what would you do?:
@coldandtired said in If you could make breaking changes to C#, what would you do?:
@djls45 said in If you could make breaking changes to C#, what would you do?:
case 1: perform1stuff(); break; case 2: perform2stuff(); /* I think C# will complain here about not having a break...? */ case 3: perform2and3stuff(); /* C# will not execute this for 2, but C will. */ break; case 4: case 5: /* C# and C both fall through here. */ perform4_5stuff(); break;
C# will do exactly what your example shows without any breaks at all (or rather, it could but instead complains about the missing breaks).
The only use I see for it is something like
switch (Colour) { case RED: DoStuff(); break; case ORANGE: break; // Fuck orange case YELLOW: case GREEN: DoOtherStuff(); break; default: DoSomethingElse(); break; }
Where there is a do-nothing choice as well as a default choice, but I wonder how common or how recommended that is.
I think you missed this part:
case 2: perform2stuff(); /* I think C# will complain here about not having a break...? */ case 3: perform2and3stuff(); /* C# will not execute this for 2, but C will. */ break;
The handling for
2
is split across both, because3
also shares part of the handling for2
.It could be done if continue statement could be extended to be used in here.
The only issue with using
continue
here is that it would break (hehe) usingcontinue
inside loops that surround theswitch
statement. But I guess that is on-topic. :D
-
@djls45 On the other hand,
switch
already commandeersbreak
, so
-
@cheong said in If you could make breaking changes to C#, what would you do?:
If all your classes are put on global namespace
Anyone who actually does this is an idiot.
@cheong said in If you could make breaking changes to C#, what would you do?:
The more classes in the "visible scope" of the class your working on, the longer compile time needed to resolve them, and the less responsive your IDE would be when with Intellisense enabled.
The number of classes you'd need to see a significant difference would make the namespace so unfeasibly large that you'd want to split it up anyway.
-
@djls45 why?
-
@lucas1 said in If you could make breaking changes to C#, what would you do?:
@djls45 why?
So you need not add code for similar processing that just appends some task at the end.
The "goto case" is better in the sense the it allows you to omit creating code segments that only differs in the start/middle/end. All you need to do is predefine value that indicates end of common part.
EDIT: Just common end part, not start.
-
@cheong Sounds complicated e.g. I couldn't give a fuck.
-
@lucas1 said in If you could make breaking changes to C#, what would you do?:
@cheong Sounds complicated e.g. I couldn't give a fuck.
Currently you'll need to do something like this:
switch (controlvariable) { case 1: { } break; // ... normal switch block for individual values here } switch (controlvariable) { case 1: case 3: case 5: { // common ending code for odd number cases } break; case 2: case 4: case 6: { // common ending code for even number cases } break; }
But with "goto case" you can do this:
switch (controlvariable) { case 1: { } goto case -1; case 2: { } goto case -2; case 3: { } goto case -1; case 4: { } goto case -2; case 5: { } goto case -1; case 6: { } goto case -2; case -1: // preallocated value for odd number end processing { } break; case -2: // preallocated value for even number end processing { } break; }
-
@lucas1 said in If you could make breaking changes to C#, what would you do?:
@blakeyrat they are ints so I don't think that is possible.
Suggest a chance to C#, and have Lucas1 tell you why that change CAN NEVER HAPPEN!!!
Come on, man, get in the spirit of the thing.
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
@lucas1 said in If you could make breaking changes to C#, what would you do?:
@blakeyrat they are ints so I don't think that is possible.
Suggest a chance to C#, and have Lucas1 tell you why that change CAN NEVER HAPPEN!!!
Come on, man, get in the spirit of the thing.
I am all for you telling me why I am wrong.
-
@lucas1 said in If you could make breaking changes to C#, what would you do?:
I am all for you telling me why I am wrong.
The fact that
enum
values are ints is implementation-detail. There's no reason they need to be ints, especially for enums where you don't explicitly assign values to them.I'd argue:
enum Plarps { Froog, Smerk, Weewto, }
Those enum values should not be auto-converted to int. Moreover, if you define an enum like this and then use an enum value in a context where it would be auto-converted to an int, C# should throw a type error at compile-time. Because don't do that!
If you define your enum like:
enum Plarps { Froog = 1, Smerk = 2, Weewto = 3, }
Than they should.
And that's not even the point. The point is: get into the spirit of the thing. Stop being grumpy. If you hate all these ideas and proposals, go look in another topic, maybe it'll have cat gifs for you.
-
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
should throw a type error at compile-time
Using 1 developer's time fixing a bug is a lot better than using millions of users' time coping with broken software.
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
Speaking of
switch
:Syntax to tell C# "I'm switching on an
enum
, if a new value is added to theenum
definition throw a syntax error at build time".enum People { Bob, Ted }; var peeps = People.Bob; switch( peeps as all People ) // No idea what this syntax would look like { case Bob: blah(); break; } // Syntax error: "not all values of enum People represented inside switch statement"
You cannot define methods in enums in C#?
-
@homobalkanus said in If you could make breaking changes to C#, what would you do?:
You cannot define methods in enums in C#?
No, but I don't see how that would help...
-
@unperverted-vixen said in If you could make breaking changes to C#, what would you do?:
@homobalkanus said in If you could make breaking changes to C#, what would you do?:
You cannot define methods in enums in C#?
No, but I don't see how that would help...
Coming from Java. You can define an abstract method in an enum which every value is then required to implement. Not implementing for a new value results in compile-time error
-
@homobalkanus Ah, that makes sense. I was only thinking of methods on the overall enum type, which obviously wouldn't be of use.
I think there's use cases for both - if it's your enum, and nobody else is consuming it, that approach from Java would work (and is better from an OOP design perspective). But if you're working with an enum you can't extend, something like @blakeyrat's suggestion would be the only way to solve it.
-
@homobalkanus said in If you could make breaking changes to C#, what would you do?:
Coming from Java. You can define an abstract method in an enum which every value is then required to implement. Not implementing for a new value results in compile-time error
If you can do that in C#, I'm not aware of it.
But that doesn't solve the problem. What if the enum's in someone else's library?
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
@homobalkanus said in If you could make breaking changes to C#, what would you do?:
Coming from Java. You can define an abstract method in an enum which every value is then required to implement. Not implementing for a new value results in compile-time error
If you can do that in C#, I'm not aware of it.
But that doesn't solve the problem. What if the enum's in someone else's library?
Abstract virtual extension methods? They'd be a nightmare to try to write a compiler for, but you could, I guess.
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
@homobalkanus said in If you could make breaking changes to C#, what would you do?:
Coming from Java. You can define an abstract method in an enum which every value is then required to implement. Not implementing for a new value results in compile-time error
If you can do that in C#, I'm not aware of it.
But that doesn't solve the problem. What if the enum's in someone else's library?
True. I was thinking about enums under your control.
-
Wild ideas time: extend
switch
to allow it to be able to use regular expressions to match strings, as opposed to just literals as at the moment. I'm not sure how the syntax would look :) but maybe like this spitballed mess:switch (theString) using regexps { case /abc.*def/: DoSomething(); break; case /ghi(.{3,5})jkl/ -> (match, submatch): // capturing the sub-expression DoSomethingElse(submatch); break; }
The naΓ―ve implementation would have to test each RE in order I guess β someone smart might be able to make a cleverer way in some cases β but it's the sort of thing that would make quite a lot of parsing tasks much less annoying.
-
@dkf Speaking of REs, I'd add regex literals.
-
@blakeyrat Unless I'm mistaken, C# already allows you to specify the type of an enum to be something other than
int
.
-
@raceprouk But it's limited to
short
,int
,long
, andchar
I believe. Because, as Blakey has pointed out, they have that dumb chars-can-be-ints brainworm.
-
@raceprouk said in If you could make breaking changes to C#, what would you do?:
@blakeyrat Unless I'm mistaken, C# already allows you to specify the type of an enum to be something other than
int
.It does? So it does. Neat, I can
abuse that.enum MassUnits : decimal { mg = 0.001, g = 1, kg = 1000 }
-
@magus said in If you could make breaking changes to C#, what would you do?:
@raceprouk But it's limited to
short
,int
,long
, andchar
I believe. Because, as Blakey has pointed out, they have that dumb chars-can-be-ints brainworm....dammit.
New proposal:
- Enums can be (at least) any numeric type.
-
@coldandtired said in If you could make breaking changes to C#, what would you do?:
@djls45 said in If you could make breaking changes to C#, what would you do?:
case 1: perform1stuff(); break; case 2: perform2stuff(); /* I think C# will complain here about not having a break...? */ case 3: perform2and3stuff(); /* C# will not execute this for 2, but C will. */ break; case 4: case 5: /* C# and C both fall through here. */ perform4_5stuff(); break;
C# will do exactly what your example shows without any breaks at all (or rather, it could but instead complains about the missing breaks).
The only use I see for it is something like
switch (Colour) { case RED: DoStuff(); break; case ORANGE: break; // Fuck orange case YELLOW: case GREEN: DoOtherStuff(); break; default: DoSomethingElse(); break; }
Where there is a do-nothing choice as well as a default choice, but I wonder how common or how recommended that is.
What if
ORANGE
contains a single statement, currently commented out for debugging?
-
@dreikin said in If you could make breaking changes to C#, what would you do?:
@magus said in If you could make breaking changes to C#, what would you do?:
@raceprouk But it's limited to
short
,int
,long
, andchar
I believe. Because, as Blakey has pointed out, they have that dumb chars-can-be-ints brainworm....dammit.
New proposal:
- Enums can be (at least) any numeric type.
Why limit it to numerics? Why not a string enum?
-
@anonymous234 said in If you could make breaking changes to C#, what would you do?:
@dreikin There's Boo, which seems to be pretty much C# with Python syntax.
...and metaprogramming, which is what really makes it awesome.
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
(The current DateTime should either be chucked in the bin or given an appropriately scary name so developers understand it's very prone to causing hard-to-find bugs.)
Funny, back when I was learning C#, you suggested I check out the DateTime code as an example of how to do C#.
-
@masonwheeler said in If you could make breaking changes to C#, what would you do?:
@maciejasjmj said in If you could make breaking changes to C#, what would you do?:
But when it's a type, things get less fun:
public class EnumerableCounter<T> where T : IEnumerable<...oops?>
public class EnumerableCounter { int Count<T> (IEnumerable<T> thingToCount) { ... } }
???
class Foo : IEnumerable<String> { ... }
class Program { static void Main(string[] args) { Bar(new Foo()); } static void Bar<T>(T x) where T : IEnumerable<object> { } }
-
@captain said in If you could make breaking changes to C#, what would you do?:
Funny, back when I was learning C#, you suggested I check out the DateTime code as an example of how to do C#.
Yes, well, it's impossible for anybody to learn new information or change their opinion over time, so I guess that means I'm a huge stupid hupocrite.
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
Yes, well, it's impossible for anybody to learn new information or change their opinion over time, so I guess that means I'm a huge stupid hupocrite.
Wrong again. ;-)
(The joke being I wasn't implying anything like that... but even good C# sucks)
-
@dkf said in If you could make breaking changes to C#, what would you do?:
Wild ideas time: extend
switch
to allow it to be able to use regular expressions to match strings, as opposed to just literals as at the moment. I'm not sure how the syntax would look :) but maybe like this spitballed mess:switch (theString) using regexps { case /abc.*def/: DoSomething(); break; case /ghi(.{3,5})jkl/ -> (match, submatch): // capturing the sub-expression DoSomethingElse(submatch); break; }
The naΓ―ve implementation would have to test each RE in order I guess β someone smart might be able to make a cleverer way in some cases β but it's the sort of thing that would make quite a lot of parsing tasks much less annoying.
Running string to multiple RegEx could be slow as hell, especially those backtracking ones.
And unlike the current nested if implementation, you'd have no idea on which RegEx in the code block casing the slowness.
-
@raceprouk said in If you could make breaking changes to C#, what would you do?:
@blakeyrat Unless I'm mistaken, C# already allows you to specify the type of an enum to be something other than
int
.Actually, I think it's possible to use it on any type if it implements Object.GetHastCode() and you use it for the switch variable. Except that since currently case statement requires you to specify a constant, so this will not work for now.
-
@raceprouk said in If you could make breaking changes to C#, what would you do?:
@dreikin said in If you could make breaking changes to C#, what would you do?:
@magus said in If you could make breaking changes to C#, what would you do?:
@raceprouk But it's limited to
short
,int
,long
, andchar
I believe. Because, as Blakey has pointed out, they have that dumb chars-can-be-ints brainworm....dammit.
New proposal:
- Enums can be (at least) any numeric type.
Why limit it to numerics? Why not a string enum?
String enum is supported already and in C# v6 you can use any integral types.
So it's something already done.
-
@cheong said in If you could make breaking changes to C#, what would you do?:
Except that since currently case statement requires you to specify a constant
Nope, not since C# 7 came out.
-
@cheong said in If you could make breaking changes to C#, what would you do?:
@raceprouk said in If you could make breaking changes to C#, what would you do?:
@blakeyrat Unless I'm mistaken, C# already allows you to specify the type of an enum to be something other than
int
.Actually, I think it's possible to use it on any type if it implements Object.GetHastCode() and you use it for the switch variable. Except that since currently case statement requires you to specify a constant, so this will not work for now.
@cheong said in If you could make breaking changes to C#, what would you do?:
@raceprouk said in If you could make breaking changes to C#, what would you do?:
@dreikin said in If you could make breaking changes to C#, what would you do?:
@magus said in If you could make breaking changes to C#, what would you do?:
@raceprouk But it's limited to
short
,int
,long
, andchar
I believe. Because, as Blakey has pointed out, they have that dumb chars-can-be-ints brainworm....dammit.
New proposal:
- Enums can be (at least) any numeric type.
Why limit it to numerics? Why not a string enum?
String enum is supported already and in C# v6 you can use any integral types.
So it's something already done.
We're talking about enum, not what you can use in switch ... case statements
-
@dreikin said in If you could make breaking changes to C#, what would you do?:
@cheong said in If you could make breaking changes to C#, what would you do?:
@raceprouk said in If you could make breaking changes to C#, what would you do?:
@blakeyrat Unless I'm mistaken, C# already allows you to specify the type of an enum to be something other than
int
.Actually, I think it's possible to use it on any type if it implements Object.GetHastCode() and you use it for the switch variable. Except that since currently case statement requires you to specify a constant, so this will not work for now.
@cheong said in If you could make breaking changes to C#, what would you do?:
@raceprouk said in If you could make breaking changes to C#, what would you do?:
@dreikin said in If you could make breaking changes to C#, what would you do?:
@magus said in If you could make breaking changes to C#, what would you do?:
@raceprouk But it's limited to
short
,int
,long
, andchar
I believe. Because, as Blakey has pointed out, they have that dumb chars-can-be-ints brainworm....dammit.
New proposal:
- Enums can be (at least) any numeric type.
Why limit it to numerics? Why not a string enum?
String enum is supported already and in C# v6 you can use any integral types.
So it's something already done.
We're talking about enum, not what you can use in switch ... case statements
I'm talking about extending the type of things you can use in case statement, not Enum.
-
@cheong And? We're still talking about
enum
.
-
@dreikin said in If you could make breaking changes to C#, what would you do?:
Why add the braces?
Because scope. In C, switch is a jump table and all variables share scope across all cases. There's no excuse for this in a modern language and all cases should have separate scopes. Braces make the lexical scope match. Braces should be mandatory everywhere.
(Did somebody beat me to this? I'm late to the party)
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
It would be nice if C# supported doing that with different types
Java does that.
-
@raceprouk said in If you could make breaking changes to C#, what would you do?:
To hide inner implementation details in a library.
Java chains exceptions so a JDBC driver can, for example:
try { connectToDatabase(); } catch (final IOException e) { throw new SQLException("Failed to connect to database", e); }
and the application programmer only deals with SQLException but the full stack trace of the root cause can give important information when trying to track down the problem.
-
@another_sam So can C#:
try { ConnectToDatabase(); } catch (IOException e) { throw new SqlException("Failed to connect to database", e); }
-
@the_quiet_one said in If you could make breaking changes to C#, what would you do?:
What about forcing package names to reflect the folder structure? My current job takes full advantage of this lack of requirement and it pisses me off.
Java does that.
People seem to dislike it. These days with modern IDEs I think it's probably less important but it does encourage better organisation of code.
The more important thing about package names in Java is the convention that they follow a DNS domain name you control. Those DNS domain names are globally allocated so there's very little chance of conflict.
-
@raceprouk said in If you could make breaking changes to C#, what would you do?:
@another_sam So can C#:
try { ConnectToDatabase(); } catch (IOException e) { throw new SQLException("Failed to connect to database") { InnerException = e }; }
You have demonstrated a feature I wish Java had, although I think in C# it's limited to property initialisation and the more general case would include other initialisation code as well.
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
The fact that enum values are ints is a lack of imagination from a C/C++ programmer
Java's enums are types, and types in Java are objects, therefore enums are objects with properties and methods and everything.
-
@dkf said in If you could make breaking changes to C#, what would you do?:
The naΓ―ve implementation would have to test each RE in order I guess
Would the compiler warn you if two regexes could match the same input? It seems to me that a switch is really only appropriate for mutually exclusive cases, and it's obvious that there's no way for the compiler to know if two cases expressed as regexes are mutually exclusive.
-
@unperverted-vixen said in If you could make breaking changes to C#, what would you do?:
if you're working with an enum you can't extend
That's exactly what enums are supposed to be. An exhaustive list of values. An enum you can extend isn't an enum at all.