On Tue, Sep 10, 2024, at 10:00, Mike Schinkel wrote:
>> On Sep 9, 2024, at 5:35 PM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk>
>> wrote:
>>
>> On 09/09/2024 19:41, Mike Schinkel wrote:
>>> In Go you cannot add or subtract on a typedef without casting to the
>>> underlying type. I would definitely prefer that to be relaxed, but only
>>> if it is relaxed via an explicit opt-in, e.g. something maybe like
>>> this:
>>>
>>> typedef UserId: int operations: +, -, *, /;
>>> typedef UserName: string operations: .;
>> I think this would stray into some of the same complexity as operator
>> overloads on objects, in terms of the types and values allowed. For instance:
>>
> I tend to agree that allowing operations may be too much for an initial scope
> given that it is unlike anything else in the current language and with no
> other languages offering an equivalent AFAIK.
>
> I would however make the distinction that it is unlike operator overloading
> because the big concern was what constituted an operation for any given type
> could be too subjective. In your example of `Metres` it is pretty obvious,
> but not at all obvious for a `User`, for example. (BTW, thank you for not
> calling out my nonsensical example of operations on a `UserId`; when I wrote
> that I clear was not thinking about if they were relevant, doh!)
>
> However give the suggestion regarding operations with a typedef, the only
> operations that I suggested would be valid would be the ones already defined
> on the underlying type, (when I mentioned other operations I was thinking of
> methods — see my the following example with round — not operators so that is
> not the same as operator overload.) For example:
>
> /**
> * Currency is an int so for example in USD 1
> * unit of currency not a dollar but a cent.
> */
> typedef Currency: int operations: +,-,*,/,round;
> function CalcTotal(Currency $subTotal, Currency $shipping, float
> $tax):Currency {
> return round($subTotal*(1+$tax/100),0) + $shipping;
> }
This is very similar (behaviorally) to what I wanted to do with GMP.
Overloading GMP would have given you int-like powers in your type. The biggest
negative feedback I got was that people would abuse it still; so we need some
way to prevent abuse. If you read Jordon's operator overloads RFC, and my GMP
overloading RFC, you can see that users basically need a way to define how to
operate over even just an integer.
For example, Dollar(1) + Euro(3) is what? Or even Dollar(1) + 1? How does a
developer prevent someone from doing something nonsensical? The language needs
to enforce some rules and/or the developer needs to be able to define them.
These rules need to be intuitive and well reasoned, IMHO.
>> typedef Metres: int;
>>
>> assert( Metres(2) + Metres(1) === Metres(3) ); // most obvious
>> assert( Metres(2) + 1 === Metres(3) ); // seems pretty clear
>
> Both of those are in line with what I was suggesting.
>>
>>
>> $_GET['input'] = '1';
>> assert( Metres(2) + $_GET['input'] === Metres(3) ); // might be more
>> controversial
>>
>>
> I would not consider this appropriate as it has two levels of conversion and
> could thus end up with unintended edge cases. To do the above I think you
> would have to either convert or typecast:
>
> assert( Metres(2) + intval($_GET['input']) === Metres(3) );
> assert( Metres(2) + (int)$_GET['input'] === Metres(3) );
>>
>>
>> typedef Feet: int;
>> assert( Metres(2) + Feet(1) === Metres(3) ); // almost certainly a bad idea
>>
>>
> This would be operator overloading where knowledge of the conversion between
> meters and feet would be required, and that is not in any way in scope with
> what I was suggesting.
>
> As an aside, I am against userland operator overloading as I have seen in
> other languages that operator overloading gets abused and results in code
> that is a nightmare to maintain. OTOH, I would support operator overloading
> in specific cases, e.g. a `Measurement` class in PHP core could allow adding
> meters to feet, assuming such a proposal were made and all other aspects of
> the RFC were of the nature to be voted in.
>
> To reiterate on typedefs, what I was suggesting was that if an operation was
> explicitly allowed — e.g. + — then anything that would work with the
> underlying type — such as adding an int 1 would work without typecasting and
> yet still result in the typedef type, e.g. Meters(2) + 1 results in a value
> of type Meters. (note that I corrected your spelling of 'Meters' here. ;-)
>
> But I agree, this is probably a bridge too far for a first RFC for typedefs.
>
>>> type MyNewType: Foo
>>> type MyAlias = Foo
>> I know this was only an example, but as a general point, I think we should
>> avoid concise but cryptic differences like this. PHP is generally
>> keyword-heavy, rather than punctuation-heavy, and I think that's a valid
>> style which we should keep to.
>>
> Here, I also tend to agree WRT PHP. Was just pointing out for sake of laying
> out other options that were implied not to exist.
>
> -Mike
In other news, I'm highly considering refactoring the records RFC to be a
typedef RFC; the infrastructure is there; we just need more restrictions.
— Rob
