Add arithmetic between Points and f64s.

[derekdreery]

This PR adds some convenience functions for adding (f64, f64) to a point.

Potential reasons not to do this: less type safety than using Vec2? I don't think this is an issue, but other opinions may differ.

[cmyr]

I think my preference is to only have the arithmetic operations on the actual types? I appreciate it is unlikely to be a concern in practice, but by having to construct a Vec2 first the operation is explicit. Point + Size or Point + Point are meaningless, but Size + Size isn't; If we also impl these here we're saying that (f64, f64) can be a vec in some circumstances and a size in another.

For a similar reason, we don't implement From<Size> for Vec2 or From<Vec2> for Point; we want to force explicit casts, to ensure the user doesn't pass a Vec2 to some method that takes an impl Into<Point> argument.

So yea, on some vague conceptual level this makes me uneasy.

I'm curious about the case that motivated this? Are you wanting to avoid bringing Vec2 into scope?

[raphlinus]

I'm also on the fence, but maybe a little more sympathetic. In my own work, I found myself not infrequently casting back and forth between Point and Vec2, and honestly it often felt more like type theater than accurately capturing the underlying concepts. To my mind, the intent of these methods is fairly clear, and it's certainly less noise than adding an additional Vec2::new() or what not. I'm also curious about the motivation, but feel I can be convinced.

[derekdreery]

For context: here is the function where I would use the impl

/// Paint the actual physical fader that you move up and down.
fn fader(bounds: Rect, fg_brush: &Brush, bg_brush: &Brush, ctx: &mut PaintCtx) {
    const MIDDLE_LINE_BORDER: f64 = SLIDER_HEIGHT * 0.1;
    let middle_y = bounds.center().y;
    let center_line = Line::new(
        (bounds.x0 + MIDDLE_LINE_BORDER, middle_y),
        (bounds.x1 - MIDDLE_LINE_BORDER, middle_y),
    );

    // This shape is essentially a rectangle, but with a little bit of concave curve on the long sides.
    // TODO make this function independent of position (so that the path can be cached)
    const CURVE_FACTOR: f64 = 0.15;
    let shape = vec![
        PathEl::MoveTo(Point::new(bounds.x0, bounds.y0)),
        PathEl::QuadTo(
            bounds.center() - Vec2::new(0.0, bounds.height() * (0.5 - CURVE_FACTOR)),
            Point::new(bounds.x1, bounds.y0),
        ),
        PathEl::LineTo(Point::new(bounds.x1, bounds.y1)),
        PathEl::QuadTo(
            bounds.center() + Vec2::new(0.0, bounds.height() * (0.5 - CURVE_FACTOR)),
            Point::new(bounds.x0, bounds.y1),
        ),
        PathEl::ClosePath,
    ];

    ctx.fill(&*shape, bg_brush);
    ctx.stroke(&*shape, fg_brush, 1.5);
    ctx.stroke(center_line, fg_brush, 2.0);
}

The change would be purely aesthetic and would remove the Vec2::new tokens. You wouldn't be able to do it the other way round: the left operand must be a Point. The argument for is that it reduces noise whilst maintaining or improving description of intent.

[raphlinus]

On balance, I think this is an improvement in readability. Thanks!

(do you need commit privs?)

[derekdreery]

I don't have commit privs here, just druid atm.

[derekdreery]

I think the key argument is that because you have chosen a Point as the left operand, you know you are applying a delta to it - it can't really be mis-construed as anything else.