[Proposal] Functions with explicit type constraint

[TheCelticGuy]

Hello

One thing that i have found frustrating with logic bugs occurring without realising is when passing in data that auto converts to the required type that the function expects.

For example i have a Vector2D and a Vector3D struct that has implied conversion of 3D(x,y,z) => 2D(x,y) or 2D(x,y) => 3D(x,y,0).

Now if i have a function that takes Vector3D types:

public Vector3D SomeFunction(Vector3D a, Vector3D b) {}

And you accidently passed in a 2D vector it will auto convert and you lose information (the z axis in this case since it will be set to 0) when you may not have intended for this to be the case.

So it would be nice if you set a function to be explicit. That would not allow a type which has implied conversion to be passed to it. So even if Vector2D is implied to be converted to Vector3D the function will still not allow it.

You could do something like:

public explicit Vector3D SomeFunction(Vector3D a , Vector3D b) {}

Thus if you do:

Vector2D a = new Vector2D(1,2); //note this is the wrong type
Vector3D b = new Vector3D(1,3,7);
Vector3D result = SomeFunction(a,b); // error type must be exact due to explicit declaration

This explicit declaration will ignore the fact that the vectors have the declarations:

implicit operator Vector3D
implicit operator Vector2D

[maxkatz6]

I hope, it should be handled with analyzers, not by language.

[TheCelticGuy]

I hope, it should be handled with analyzers, not by language.

Maybe but i for one like writing tools that are strict and leave little room for unintended mistakes later on - this would solve that by allowing functions to be strict or not. But implicit casting is still convenient else where so removing implied casting although fixes the issue, makes other things less convenient for those using the tools. At least thats how i see, just adding options for programmers that can reduce mistakes.

[yaakov-h]

i for one like writing tools that are strict ...

so then write a tool (analyzer) that does it...?

[TheCelticGuy]

so then write a tool (analyzer) that does it...?

Sure more work to do rather than working on the actual tools themselves where C# can provide the feature. Half the features in C# are for convenience which most people could work around so i don't see why this one is so beyond that idea.

[YairHalberstadt]

In my opinion this is an unwise use case for an implicit cast for the precise reason that in most cases you want to be very deliberate about treating a Vector2d as a Vector3d and vice versa.

Implicit casts in C# do not compose well and can lead to all sorts of problems. They should be used exceedingly sparingly. Numeric types are one of the very few exceptions. Similarly valuetypes which follow a logical type hierarchy but cannot inherit because structs are all sealed.

[TheCelticGuy]

In my opinion this is an unwise use case for an implicit cast for the precise reason that in most cases you want to be very deliberate about treating a Vector2d as a Vector3d and vice versa.

Implicit casts in C# do not compose well and can lead to all sorts of problems. They should be used exceedingly sparingly. Numeric types are one of the very few exceptions. Similarly valuetypes which follow a logical type hierarchy but cannot inherit because structs are all sealed.

Fair point but thats some times isn't something you have the luxury of having any control over if the type was some one else's creation and you're perhaps writing extension methods outside of the library for example.

[YairHalberstadt]

Don't use badly designed libraries. They will have millions of issues, and the compiler can't protect you from all of them.

[TheCelticGuy]

Don't use badly designed libraries. They will have millions of issues, and the compiler can't protect you from all of them.

lol its not always that simple, you work with what you're given at work ya know. Companies use old or in house libraries and don't like to change often. You surely understand that?

It's really not a big protection, half the the stuff in C# could be removed and just be "use better libraries" anyway. All it has to do is see the function has explicit and thus ignore the implicit casting. But never mind doesn't seem like people understand the benefit of it.

[YairHalberstadt]

The point is, once you are using a library which has made bad design choices, the compiler is very limited in its ability to help you. Yes it could warn on uses of implicit casts where you don't want them. But that's an oddly specific thing to call out. There's thousands of ways libraries could have made bad design choices which you don't want to affect you. Should C# provide a way to warn on uses of all of them? Where does this end?

Analysers are a great way for you to get the support you need right now for the libraries you are using, without C# having to add a hundred new language features.

[theunrepentantgeek]

But never mind doesn't seem like people understand the benefit of it.

I don't believe this is at all accurate - it's a feature that has very limited applicability, and you're asking the C# language team to invest all of the required time to design, specify, implement and test the feature for C#. This includes testing for future version of C#.

Remember that every feature starts at -100 points and needs to provide significant value just to reach a threshold worth considering.

[Flutterish]

Implicit should never lose data. Thats the whole point of it, to make "equivalent" types interchangable. Someone making Vector3 -> Vector2 implicit clearly didn't know this.

Use an analizer and tell it to never use that specific implicit operator.