CGPoint and CGRect related proposal

Evolution Discussion
,
1
  1. Name
    Since CGPoint and CGRect is also in swift standard library and can be used in Linux and other platform.

Why not we just drop the CG (Which means Core Graphics) prefix to be just like Point and Rect as a struct?

We could also add a type alias typealias Point = CGPoint to get a smooth transition

  1. Addable Protocol

The name of the protocol should not be "Addable" since we also want to support Subtraction, this is just an example name

I think it is nature to have 2 CGPoint/CGRect to be added up. Is there some protocol like "Addable", and give a +=/+ operator function to it? If so, I think we should make CGPoint and CGRect to be addable or something else.

Otherwise for me almost every-time I encounter the usage of them, I have to manually write the following trivial code or copy from the repo like GitHub - kodecocodes/SKTUtils: Sprite Kit helper classes and functions. From the book iOS Games by Tutorials.

extension CGPoint {
  public func + (left: CGPoint, right: CGVector) -> CGPoint {
    return CGPoint(x: left.x + right.dx, y: left.y + right.dy)
  }

  public func += (left: inout CGPoint, right: CGVector) {
    left = left + right
  }
}

Adding or Subtraction is a very basic operator on such type.

So I think it worth it to be implemented in the Standard Library

2

Related post: How do you forward operators to related types? (e.g. CGPoint, CGVector, SIMD2)

1 Like
3

We still have "Point" and "Rect" in MacTypes, but I don't believe they are used, so what you are saying might be possible. (We also have Size in there but that's long.)

"func +", as well as point * matrix, etc is what I also have. I believe this belongs to CoreGraphics domain.

4

Those types aren't in the standard library.

  • For Apple platforms, they are in CoreGraphics, which is re-exported by Foundation.

  • For non-Apple platforms, they are in swift-corelibs-foundation.

5 Likes
5

Without commenting on anything else, I just want to say that “adding points” is not mathematically sound.

You can subtract points to produce a vector: let v1 = p1 - p2.

You can add a point and a vector to produce another point: let p2 = p1 + v1 (or v1 + p1).

But “adding two points” is not meaningful. If you think that you want to add two points, you almost certainly actually want to be using vectors, not points at all.

• • •

…anyway, to answer the original question, the protocol for addition is AdditiveArithmetic. And yes, it would make sense for CGVector to conform.

• • •

Also, this thread seems like a better fit for Evolution: Discussion rather than Development: Standard Library (where it is currently located).

6 Likes
6

Thanks for your reply.

Yes, CGVector may be a better case for that. And actually it already has static var zero: CGVector { get }

Also moved this post to Evolution: Discussion.

7

I would welcome this change, but I think it is only feasible if it's also accompanied by a shift in conventions/style-guides in the community: we need to embrace people defining their own types with conflicting* names.

People will certainly have a need to model common things like points, vectors, rects, etc. in their code-bases. If these standard library provided types don't fit their needs, I would want these authors to feel free to make their own Point, Vector, etc. (TheirModule.Point, TheirModule.Vector, ...), without facing the wrath of the part of the dev community which insists that shadowing library types is a cardinal sin (which is what I gather to be the contemporary opinion on the matter, but I could be mistaken).

Without this shift in convention, I fear this change would be un-weclome, because we would be "using up" such valuable/common type names.

* They aren't actually conflicting: Swift's module-based name-spacing (and the name mangling that happens as a result) makes it a non-issue, unlike C/ObjC

1 Like
8

Imho it would be cool and really beneficial for the platform to have a set of libraries with fundamental types and interfaces, so that third party libs could use a common basis. I can hardly think of anything else which could give us as much bang for the buck, and it could lower the barrier for people to participate drastically.
So I'd really appreciate to not only have a place for points and rectangles, but also for paths, pixel data, audio and some other fundamental structures (not a single lib for all topics, though ;-)