Shouldn't Size & SizeF be replaced by Point & PointF?

[br3aker]

Point/Size & PointF/SizeF pairs contain equal code and test cases for both Point and Size counterparts, shouldn't they be merged?

They even have conversions between each other:

ImageSharp/src/ImageSharp/Primitives/Size.cs

Lines 62 to 66 in 993f96e

	public Size(Point point)
	{
	this.Width = point.X;
	this.Height = point.Y;
	}

ImageSharp/src/ImageSharp/Primitives/Size.cs

Lines 95 to 96 in 993f96e

	[MethodImpl(MethodImplOptions.AggressiveInlining)]
	public static explicit operator Point(Size size) => new Point(size.Width, size.Height);

Both these changes would break API unfortunately but isn't it possible to be set to some "Future"/"2.0" major milestone?

[tocsoft]

No they should not... they are conceptually different. Yes from purely a data point of view they could easily be a single type but from an API/code understanding point of view they are very different.

If it was a single shared type it would cause way too much additional cognitive load requirements forced onto our users and make our APIs way less self documenting. You must not forget that source code is not really for machines/the compiler first its for developers first and the compiler second. The reason for that is developers are going to to have to read and mentally process the code as they write it today, and in several years time when they have to come back to maintain it, so its really important they they can understand what the code means without having to keep too much additional state in there heads. For example much easier to reason about foo.Width is a width and bar.X is a location rather then foo.X is a location unless when its a width which is dependent where foo was read from 2 method calls ago.

[br3aker]

Can't agree.
Example names foo & bar are not very descriptive in this context. Entire codebase is populated with either this Size somethingSize or this: Size somethingDimension.

I dont see any problem determining what dimension.X or image.Size.X is. Same applies to points.

image.Size.Width simply duplicates the meaning stating that width is a size component which is obvious from its name, image.Width looks much cleaner.

On the other hand, Size size = foo.Size is worse than Vector2 size = foo.Size because just from definition you can tell that this is a vertical/horizontal value without checking intellisence/source code/docs/comments.

Furthermore, if Point/Size segregation was about conceptual difference, how can you add or substract size from point (vector, basically)?

ImageSharp/src/ImageSharp/Primitives/Point.cs

Line 177 in 993f96e

public static Point Add(Point point, Size size) => new Point(unchecked(point.X + size.Width), unchecked(point.Y + size.Height));

From mathematical point of view, size can be empty, point can't. But both can be zero, for example.

ImageSharp/src/ImageSharp/Primitives/Point.cs

Line 24 in 993f96e

public static readonly Point Empty = default;

There also are substraction and addition for Size which makes no sense.

Core reasoning behind this for me is that instead of supporting 4 different types + test cases for all 4, this library can support 2 + 2 or even 1 + 1 considering System.Numerics already defines Vector2 of floats and naming convention is okay.

P.S.
IMO, Vector2 and Vector2Int are much better then PointF and Point because they are more accurate in terms of math but that's not that important.

[JimBobSquarePants]

Furthermore, if Point/Size segregation was about conceptual difference, how can you add or substract size from point (vector, basically)?

Easily. You add or subtract a pair of absolute values (size) from a position in 2D space.

In addition, try to imagine an API that require both a vector and dimensions.

DoSomething(Point point, Point size)

That would swiftly become a usability issue. Conceptually the following is much more clear.

DoSomething(Point point, Size size)

These types and methods exist as a continuation of the System.Drawing primitives and match their implementation exactly (warts and all, though I would be up for changing things like Empty to Zero for v2). This might not make sense to you but they do to many other people.

Ideally, for Point and PointF yes it would have been nice to only use System.Numerics where we could but when this library was started those APIs were in their infancy and we want to be able to provide that simple migration path. Personally Vector2<T> would be my preferred type, I hate the name Vector2Int.

[br3aker]

Easily. You add or subtract a pair of absolute values (size) from a position in 2D space.

Code behind it makes sense yes but you can't move a point by size of something, only by vectors.

In addition, try to imagine an API that require both a vector and dimensions.

DoSomething(Point point, Point size)

That would swiftly become a usability issue. Conceptually the following is much more clear.

DoSomething(Point point, Size size)

This should do the trick

DoSomething(Rect area)

And that's why I don't like name Point from System.Drawing 😕

DoSomething(Vector2 point, Vector2 size)

Size as a Vector2 with origin at (0,0) poiting to upper-left corner in object local space is a usual thing for people familiar with math but yeah, for usual people this might be misleading. What a shame we still don't have global type aliases in C#.

Marking as answered, thanks for the replies people!
Edit I actually can't mark it answered for some reason :(