I found an earlier post somewhere about work someone has done on physical units such as kg, volts and so forth.

It would be very good to catch bugs such as

    volts_t v = input_current;

But that isn’t nearly enough. With strong typing where we can create arbitrary subtypes that are chosen to be incompatible because they are semantically incompatible in assignment, equality, addition and various other operations, we can catch a lot more bugs.

 point1.x = point2.y;

the above is illegal but we need a way to get the underlying value so we can handle rotation by angle of 90 deg or whatever. These two variables have the same units; their unit is pixels but they cond have a real SI physical unit of length in metres say. Even when they are of the same physical units type they need to be made incompatible to prevent y coordinates from getting mixed up with x coordinates by mistake.

also

point1.x = width; // illegal

and

point1.x = height; // even worse

Arbitrary sub typing would help here but would need accompanying tools to make it usable, the ‘get underlying value’ thing mentioned earlier might not be the only one, I’m not sure.

Any thoughts ?

—
I tried to do something with wrapping a double say in a (templated) struct with just one field value_ in it and an alias value_ this; but as a miserable D learner, I soon got lost.

for some reason when using alias this as above, I can do assignments to my struct, but I cannot initialise it using the alias this simplification mechanism. I’m not sure why. I’m assuming I need an appropriate trivial constructor but why doesn’t this get sorted out for you automatically when you’re using alias this? That would seem to be logical, no? Asking for too much - greedy :-)


Cecil Ward.

On Tuesday, 28 July 2020 at 04:40:33 UTC, Cecil Ward wrote:
> I found an earlier post somewhere about work someone has done on physical units such as kg, volts and so forth.
>
> It would be very good to catch bugs such as
>
>     volts_t v = input_current;
>
> [...]

This is easily done and uses enums: (officially defined in the specification, not even a hack!)

enum DisplayUnit : int { init = 0 }
enum Width : DisplayUnit { init = DisplayUnit.init }
enum Height : DisplayUnit { init = DisplayUnit.init }

void foo()
{
    Width width = cast(Width)16;
    Height height = cast(Height)9;

    //width = height; // illegal implicit conversion
    //width = 4; // illegal implicit conversion
    width = cast(Width)height; // legal, force conversion

    DisplayUnit val = width; // allowed implicit conversion, Width "inherits" DisplayUnit
    int num = width; // also allowed, Width "inherits" DisplayUnit which "inherits" int

    writeln(num); // 9
    writeln(width); // cast(Width)9
}

You can then also make helper functions for prettier syntax, see https://run.dlang.io/is/X4BA32

> But that isn’t nearly enough. With strong typing where we can create arbitrary subtypes that are chosen to be incompatible because they are semantically incompatible in assignment, equality, addition and various other operations, we can catch a lot more bugs.

Sadly width += height (and probably all operators other than assignment) are still allowed.

However for return codes this makes great sense: it implicitly converts down to integers if the user wishes to lose type information and otherwise prevents assigning or calling wrong functions like some example `enum Win32Error : int` could not be used to call a `validate(PosixError)` function

This is also great for opaque handles like for making file descriptors type-safe: `enum File : int`, `enum Socket : int` which you can't accidentally pass to type-safe APIs but can still easily use in C APIs using ints or raw file descriptor access. All your wrapper functions simply cast the internal C API return values to these type-safe enum types based on context they know.

For other values representing something it doesn't work as great as you need to have a helper function to construct them or always cast them as well as to!string (and writeln) don't print the raw value but rather prepend a "cast(T)" in the string, but it still works and is possible.

On Tuesday, 28 July 2020 at 04:40:33 UTC, Cecil Ward wrote:
> [snip]

By the way, I found 2 implementations of unit of measurement in D:
https://code.dlang.org/packages/units-d
https://code.dlang.org/packages/quantities

On Tuesday, 28 July 2020 at 07:16:53 UTC, Petar Kirov [ZombineDev] wrote:
> On Tuesday, 28 July 2020 at 04:40:33 UTC, Cecil Ward wrote:
>> [snip]
>
> By the way, I found 2 implementations of unit of measurement in D:
> https://code.dlang.org/packages/units-d
> https://code.dlang.org/packages/quantities

Thank you Peter! Very helpful.

Do you guys have any thoughts also about the strong typing idea?

Of course, in C I used to do something like strong typing with an opaque type achieved by using something like typedef struct _something {} * type1; and then I had to do casting to get back the real type, which was unchecked but it did prevent the user from mixing up the types type1 and type2 say as they weren’t assignment compatible.

I would really like strong typing to be a built in feature. Would anyone else support this?

I just remembered: another favourite bug of mine would be mixing up indices, using an index with the wrong array, an index to a different array entirely. they’re all just a nightmare load of meaningless ints or uints or hopefully size_t’s.

On Tuesday, 28 July 2020 at 11:04:00 UTC, Cecil Ward wrote:
> Of course, in C I used to do something like strong typing with an opaque type achieved by using something like typedef struct _something {} * type1; and then I had to do casting to get back the real type, which was unchecked but it did prevent the user from mixing up the types type1 and type2 say as they weren’t assignment compatible.
>
> I would really like strong typing to be a built in feature. Would anyone else support this?

Once upon a time, typedef was present and backed by the compiler, but nowadays you can find it in Phobos [1], but with some quirk ...

[1] https://dlang.org/phobos/std_typecons.html#.Typedef