Arithmetics operator for "point-vector" types.

[Amxx]

Abstract

Allow the definition of the add (and sub) operators with 2 differents input types

Motivation

Two basic concepts in geometry, are Points and Vectors. It makes sens to add, or even subtract 2 vectors, giving a new vector. It also makes sens to add a vector to a point, giving a new point. On the other hand, it does not make sens to add to point (if you do so, you are probably assuming that a point is equivalent to the vector from the origin to it).

The same can be said of Timepoints and Durations, which are basically the same object in one dimension.

In order to improve the security of time arithmetics (clearly distinguishing times and duration using dedicated UDVT), I wanted to define

type Timepoint is uint48;
type Duration is uint40;

and then define the following functions:

function timepoints_add(Timepoint t, Duration d) pure returns (Timepoint) { return Timepoint.wrap(Timepoint.unwrap(t) + Duration.unwrap(d)); }
function timepoints_sub(Timepoint t, Duration d) pure returns (Timepoint) { return Timepoint.wrap(Timepoint.unwrap(t) - Duration.unwrap(d)); }
function durations_add(Duration d1, Duration d2) pure returns (Duration) { return Duration.wrap(Duration.unwrap(d1) + Duration.unwrap(d2)); }
function durations_sub(Duration d1, Duration d2) pure returns (Duration) { return Duration.wrap(Duration.unwrap(d1) - Duration.unwrap(d2)); }

I then wanted to defined these function as global operators:

using { timepoints_add as +, timepoints_sub as - } for Timepoint global;
using { durations_add as +, durations_sub as - } for Duration global;

and this is when I got the following errors:

TypeError: Wrong parameters in operator definition. The function "timepoints_add" needs to have two parameters of type Timepoint and the same data location to be used for the operator +.

TypeError: Wrong parameters in operator definition. The function "timepoints_sub" needs to have one or two parameters of type Timepoint and the same data location to be used for the operator -.

Note that while the first one is very clear, the second one asks "one or two parameters of type Timepoint" ... which it does have

Specification

Allow the definition of arithmetic types (add, sub, mul, div, modulo?) that have

• a first parameter for type A (main type)
• a return type A (main type)
• a second parameter of any type (secondary type)

function operator_name(A a, B b) pure returns (A)

Backwards Compatibility

N/A

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[Amxx]

This is still relevant

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[Amxx]

this is still relevant (for solidity experimental I guess)

[ekpyron]

The restriction here is very much deliberate both to reduce the minimal required expressivity for Solidity's type system logically (in experimental Solidity, the request would boil down to multi-parameter type classes/traits versus single-parameter type classes, which is a significant difference in complexity), but also to avoid the inevitable ambiguities you can introduce with a more relaxed mechanism on the language level.

I won't close the issue, since for independent reasons we may still end up with sufficient type system complexity to accommodate this in theory - but even then I'd be hesitant to expose that expressivity on the operator level (although introducing an additional operator for scalar vector space multiplication may be an option, if we find a good syntactic choice). So there may be space to accommodate this one way or another in the future, but it is generally in the first instance a non-goal.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.