Consider the following code to keep track of rectangle positions on the screen; eg: (1,2)(3,2) ie: (left,top)(right,bottom), providing get/set properties for one-based positions but only get properties for zero-based positions:

public struct gudtPosition {

   final public void reset() { pintLeft1 = pintTop1 = pintRight1 = pintBottom1 = 0; }

   private ushort pintLeft1 = 0;
   private ushort pintTop1 = 0;
   private ushort pintRight1 = 0;
   private ushort pintBottom1 = 0;

   final public const ushort left1() { return this.pintLeft1; }
   final public const ushort top1() { return this.pintTop1; }
   final public const ushort right1() { return this.pintRight1; }
   final public const ushort bottom1() { return this.pintBottom1; }

   final public ushort left0() { return this.pintLeft1 = 0 ? 0 : cast(ushort)(this.pintLeft1 - 1); }
   final public ushort top0() { return this.pintTop1 = 0 ? 0 : cast(ushort)(this.pintTop1 - 1); }
   final public ushort right0() { return this.pintRight1 = 0 ? 0 : cast(ushort)(this.pintRight1 - 1); }
   final public ushort bottom0() { return this.pintBottom1 = 0 ? 0 : cast(ushort)(this.pintBottom1 - 1); }

   final public void left1(const ushort lintPosition) { this.pintLeft1 = lintPosition; }
   final public void top1(const ushort lintPosition) { this.pintTop1 = lintPosition; }
   final public void right1(const ushort lintPosition) { this.pintRight1 = lintPosition; }
   final public void bottom1(const ushort lintPosition) { this.pintBottom1 = lintPosition; }

   final public string caption0() { return /// eg: from (24,24) to (48,48)
      r"from ("c ~
      std.format.format(r"%d"c, this.left0) ~
      r","c ~
      std.format.format(r"%d"c, this.top0) ~
      r") to ("c ~
      std.format.format(r"%d"c, this.right0) ~
      r","c ~
      std.format.format(r"%d"c, this.bottom0) ~
      r")"c;
   }

   final public string caption1() { return /// eg: from (24,24) to (48,48)
      r"from ("c ~
      std.format.format(r"%d"c, this.pintLeft1) ~
      r","c ~
      std.format.format(r"%d"c, this.pintTop1) ~
      r") to ("c ~
      std.format.format(r"%d"c, this.pintRight1) ~
      r","c ~
      std.format.format(r"%d"c, this.pintBottom1) ~
      r")"c;
   }

}

The code should be, I guess, self-explanatory to read. I do have some things to learn here on the D-specifics:

• is there a way to unambiguously specify short integers values like there is for long ones (eg: 1L means 1 long integer like: long pintSomething = 1L;) ?

• that follows to what seems to be unnecessary castings in my code snippet; if I write: ushort a = 1; ushort b = 2; ushort c; why can't I write c = a + b; ? ... DMD refuses the last one unless I explicitly write: c = cast(ushort) a + b; ... if all the variables I defined are of the same type ... why should I do have to cast() them afterwards ?

On Saturday, 5 June 2021 at 00:24:01 UTC, someone wrote:

On Saturday, 5 June 2021 at 00:24:01 UTC, someone wrote:

It looks like you’re being caught by D’s arithmetic conversions: https://dlang.org/spec/type.html#usual-arithmetic-conversions

“If the signed type is larger than the unsigned type, the unsigned type is converted to the signed type.”

Your pint variables are ushorts but the 1 you subtract is an int literal so the result gets promoted to an int.

Also, I don’t believe there is an unambiguous way to write a ushort literal: https://dlang.org/spec/type.html#basic-data-types

You should be ok with “u” if the function’s return is ushort. The compiler should be able to figure it out from there. I’m hoping I’m not wrong there as I haven’t tried it myself.

On Saturday, 5 June 2021 at 01:34:06 UTC, Kyle Ingraham wrote:

As I am writing code today I am encountering a lot of these situations.

cast(ushort)(this.pintBottom1 - 1)

My first walkaround for this was intuitive:

this.pintBottom1 - cast(ushort) 1 /// I didn't know if eg: 1S was possible which should have been the proper way to handle it

... since pintBottom was already defined as ushort, but it didn't work also, so I ended with cast(ushort)(this.pintBottom1 - 1). I don't understand how to write typed code in D then. What's the point of declaring, for instance ushort's if then nothing will treat them as ushort's and I have to manually cast() everything to ushort() all the time ?

On Saturday, 5 June 2021 at 01:46:45 UTC, someone wrote:

Yeah, it totally sucks.

D inherited a silly rule from C - the promote rules actually come from there - but then added a well-intentioned but pretty annoying in practice rule that discarding bits from arithmetic require an implicit cast. (Unless it is the bits over 32... then who cares. lol)

The += operator is exempt from it so use it where you can. But otherwise your only real hope is to do a user defined type with op overloads and what an enormous hassle.

This design was a mistake.

On Saturday, 5 June 2021 at 02:07:03 UTC, Adam D. Ruppe wrote:

Of all the great things I learned and read about it, this behavior was totally unexpected to me.

It is really difficult to code strong-typed apps this way -this behavior is really wonderful for writing loose scripts and the like and forgetting about types just to build prototypes or whatever, but, for really critical strong-typed apps is ... I'm not hurrying up to say game-over but, I can't see the way to go forward right now unless I am missing something.

Furthermore, if, at least, there was a way to clearly state what is short (eg 1S a la 1L) things will improve a lot, since any integer not having S or L could be assumed a normal integer, since byte has its own declaration. Writing code like:

ushort a; a = a - cast(ushort) 1; would be totally acceptable.

But writing code like:

ushort a; a = cast(ushort) a - cast(ushort) 1;

or

ushort a; a = cast(ushort)(a - 1);

would be totally silly and a waste of time I guess.

Right now I am totally immersed on Ali's book (and of course the tutorial and the dlang online reference) but one of the sections of Alexandrescu's book (have it in dead-tree-media) that I liked very much was the one depicting how to differentiate base types from one another with is flow charts.

At first sight I got the impression that any type could be unambiguously stated in D. Seems I was wrong.

One of the things that also immediately stuck me with D was the lack of proper nulls for all base types -meaning, for example for a string "" should not the same as null and 0 for a integer should not be the same as null, null (actually meaning dunno), and this is obviously really useful for database apps and a lot of other things.

On Saturday, 5 June 2021 at 02:38:50 UTC, someone wrote:

That actually doesn't matter. The compiler actually will automatically type it to the most narrow thing it fits. The implementation there is actually quite nice - inside a single expression, the compiler tracks the possible range.

Try:

ubyte a = 5 + 3; // just works, it knows 5+3 = 8 which can be byte

ubyte b = a & 0xff; // also works, it knows the mask limits the range

And various combinations like that. It works as long as it is in one statement.

But if you cross them:

ubyte c = a + 1;

Now it assumes a might be the maximum of 255... and 255 + 1 doesn't fit in the ubyte, thus it will not allow the assignment back.

Masking operations are a possible alternative to casting btw... but still a hassle.

This doesn't do anything since the promotion is done anyway. The compiler already knows both are ushort there, it is the arithmetic that assumes worst case scenario.

this does work though.

a -= 1; // also works

Again, it is not the type of the literal that is the problem.

D follows the C rule that all arithmetic promotes. (Seriously, try it in C, it also converts to int first before doing an add or subtract.)

But C allows it to convert back without hassle, so it is easy to ignore this annoying promotion thing. D only allows the conversion back if the compiler can prove it fits.

its not. They're very similar but it is NOT the same. Check the .ptr property.

Its not. The type system won't allow those to cross.

I've done tons of database apps in D, I've been doing web stuff with D since 2008. There's various ways to do nullable sql, it isn't a big problem.

Everything is public by default, and you can't overload and derive from structs so final has no effect

there less visual noise:

struct gudtPosition {

   void reset() { pintLeft1 = pintTop1 = pintRight1 = pintBottom1 = 0; }

   private ushort pintLeft1 = 0;
   private ushort pintTop1 = 0;
   private ushort pintRight1 = 0;
   private ushort pintBottom1 = 0;

   const ushort left1() { return this.pintLeft1; }
   const ushort top1() { return this.pintTop1; }
   const ushort right1() { return this.pintRight1; }
   const ushort bottom1() { return this.pintBottom1; }

   ushort left0() { return this.pintLeft1 = 0 ? 0 : cast(ushort)(this.pintLeft1 - 1); }
   ushort top0() { return this.pintTop1 = 0 ? 0 : cast(ushort)(this.pintTop1 - 1); }
   ushort right0() { return this.pintRight1 = 0 ? 0 : cast(ushort)(this.pintRight1 - 1); }
   ushort bottom0() { return this.pintBottom1 = 0 ? 0 : cast(ushort)(this.pintBottom1 - 1); }

   void left1(const ushort lintPosition) { this.pintLeft1 = lintPosition; }
   void top1(const ushort lintPosition) { this.pintTop1 = lintPosition; }
   void right1(const ushort lintPosition) { this.pintRight1 = lintPosition; }
   void bottom1(const ushort lintPosition) { this.pintBottom1 = lintPosition; }

   string caption0() { return /// eg: from (24,24) to (48,48)
      r"from ("c ~
      std.format.format(r"%d"c, this.left0) ~
      r","c ~
      std.format.format(r"%d"c, this.top0) ~
      r") to ("c ~
      std.format.format(r"%d"c, this.right0) ~
      r","c ~
      std.format.format(r"%d"c, this.bottom0) ~
      r")"c;
   }

   string caption1() { return /// eg: from (24,24) to (48,48)
      r"from ("c ~
      std.format.format(r"%d"c, this.pintLeft1) ~
      r","c ~
      std.format.format(r"%d"c, this.pintTop1) ~
      r") to ("c ~
      std.format.format(r"%d"c, this.pintRight1) ~
      r","c ~
      std.format.format(r"%d"c, this.pintBottom1) ~
      r")"c;
   }

}

On Monday, 7 June 2021 at 12:53:29 UTC, russhy wrote:

Gotcha !

I started using final (and the like) on classes a couple of days ago and I suppose I unconsciously dragged them to the structures, which, as you say, they can't be derived so it is non-sense.

Also: trying to suit my coding style to D code -a work in progress.

On Monday, 7 June 2021 at 14:12:14 UTC, H. S. Teoh wrote:

Your workaround seems interesting. Will look further into the concept in the coming days. I am learning the D-ways and there's so much to gather that it will take me some time to get started -I mean, evidently D has many strong-points as being highlighted in the D gems section in the tutorial, but, what really comes to mind after a week-or-so coding with it, is its flexibility: there are a lot of ways to do x stuff.