Implicit constructors with value tuples

[vpenades]

This is a wild feature suggestion, so don't take it too seriosly!

Lately, I've been experimenting with implicit constructors with value tuples for common structures that really help trimming the amount of code to write.

The best way to show this is with an example:

We usually draw a polygon like this:

image.DrawPolygon(Color, new PointF(2,2), new PointF(2,4), new PointF(4,4) );

now, if PointF would implement the implicit constructor:

public static implicit operator Pointf( (float x, float y) point)
{
    return new Pointf( point.x, point,y );
}

the previous example can be refactored into this:

image.DrawPolygon(Color, (2,2), (2,4), (4,4) );

This can be applied to several structures that require multiple construction arguments, PointF, RectangleF, maybe even colors.

Additionally, Given that System.Drawing.Common is part of NetStandard/NetCore and it is there even if you don't reference it, I've also began using some additional implicit constructors, expecting System.Drawing.Point and System.Drawing.Rectangle.

That way, you can seamlessly use System.Drawing.Point and Rectangle, in place of SixLabors primitives.

[dlemstra]

Not a fan of implicit operators and we should not add a reference to System.Drawing.Common. Also don't think we need the conversion from the System.Drawing types to the SixLabors primitives.

[antonfirsov]

Let's keep these ideas separate.

• Regarding System.Drawing.Common: long ago we decided to not depend on it, and define our primitives instead. I think we should stick to this decision. We can define conversion helpers in an interop helper library (see Library Inter-op extensions #435), but those won't be implicit.
• Regarding tuples: personally I'm not against the idea, wonder if there are any
  • Unwanted side effects?
  • Existing .NET libraries doing this?

[vpenades]

• Regarding System.Drawing.Common: long ago we decided to not depend on it, and define our primitives instead. I think we should stick to this decision. We can define conversion helpers in an interop helper library (see Library Inter-op extensions #435), but those won't be implicit.

Unless I am missing something, I believe that System.Drawing.Common is now part of NetStandard2.0 as in, you don't need to reference the nuget package, so you could say, the System.Drawing.Common types are at the same level of System.IO.Stream.

• Regarding tuples: personally I'm not against the idea, wonder if there are any...

Except myself, I have not seen anybody else using them in that way... that's why I said it was a wild proposal.

Personally, the more I used them, the more I like them, so I have some projects that use them quite extensively, even in some extreme cases (like with extensions).... but in the case of Imagesharp, I would limit it to cases where you have to create an object many times, like in the case of PointF.

I guess it's hard to see unless you begin experimenting with them...

[JimBobSquarePants]

The System.Drawing.Common drops down to netstandard 1.6 if you install the System.Drawing.Primitives library. We however target netstandard 1.3

We've also added implicit operators to our primitives + specific inlining rules to workaround some oddities in the old jitter so we wouldn't be able to use it even if we targeted 1.6 as our lowest target.

https://apisof.net/catalog/System.Drawing.Point