Something I'd like to see in C#

[andrewducker]

It's quite common to end up writing methods that take booleans to say whether certain functionality should be switched on or off. It would be nicer to use enumerations, not least because that way you couldn't end up getting them the wrong way around.

Something like:
void DoSomething(Thing thing, bool withLogging, bool withRollBack){}which would

Comments

[andrewducker]

Raised on GitHub as an issue:
https://github.com/dotnet/roslyn/issues/3497

[cartesiandaemon]

It seems like a lot of the time the parameter is a bool, in which case named parameters seem to do this?

DoSomething(thing, logging:True, rollback:False)

That's one of the things in C# which I wish C++ would hurry up and have properly.

Of course, anywhere where you do want more than two options, your enum syntax would be useful. Especially if, for the rare cases where you need it, you could use that as a variable type. And if there was a syntax that prevented the enum polluting any namespaces outside the function.

[steer]

Yes -- I was going to say named parameters too. It seems clear -- arguably more so than enumeration. (And having just designed something in a language with named parameters and had to move it to one without you realise how damn clear and useful they are.)

[cartesiandaemon]

Yeah. It's something where the lack annoys me, because it seems like you could add it with no runtime overhead, and nothing in the way of ambiguous or non-backwards-compatible syntax (if you choose the syntax well), so I can't see any obvious reason NOT to have it, and to me it looks a lot clearer (and hence more reliable).

[steer]

Nod. Last project I was working on the other coder went through a lot of hoops to ensure that two int parms distinguished only by position could not be used in the wrong order. In fact after he did that it took me ages to remember how to actually call the damn thing.

Named parameters are a big plus for me but I guess some people see it as incompatible with the style of their language. In C++ in fact I think there's no requirement that the names in a prototype and an implementation be the same so

class MyObject {
void wibble(int thisInt, int thatInt).
}

can by implemented as
MyObject::wibble(int thatInt, int thisInt);

And I imagine requiring parameter names be consistent in prototype and impl would break code? So I imagine there's scope for a lot of confusion.

[momentsmusicaux]

I've no idea whether C# supports hashes, but in Perl and PHP the way to improve this is to pass a hash/array, where the keys are the option names.

So DoSomething(myThing, [logging => TRUE, rollback => FALSE]);

[andrewducker]

It does Named Parameters (see Jack right at the top), which does the same thing, only in a statically typed manner. As I should have remembered!

[andrewducker]

C# has type inference, which might be usable here - but doesn't quite fit that model.

I suspect that any of the more complex approaches (including passing parameters down multiple layers) would be much better off declaring an enumeration normally.

Possibly what I want is just to enforce named parameters (or a simple mapping).

[andrewducker]

Thanks for the feedback, by the way - that kind of critique is exactly why I like posting things on LJ!