July 12, 2012
Am Thu, 12 Jul 2012 12:08:07 +0200
schrieb Marco Leise <Marco.Leise@gmx.de>:

> Am Thu, 12 Jul 2012 11:42:13 +0200
> schrieb Marco Leise <Marco.Leise@gmx.de>:
> 
> > Am Wed, 11 Jul 2012 22:58:07 +0200
> > schrieb "bearophile" <bearophileHUGS@lycos.com>:
> > 
> > > > => a = 5s;
> > > 
> > > I read that as "5 seconds" :-(
> > 
> > Me too, but then again "5l" could be read as 5 liters. I guess that is why the move is towards uppercase suffixes. 5S and 5L are not likely misread.
> > 
> > > I don't think your examples justify the increased language complexity.
> > > 
> > > Bye,
> > > bearophile
> > 
> > I understand that some of the examples have better alternatives. What I don't understand is why you term this as increased language complexity. This is not one of the "why not add" kind of requests. From my point of view the complexity is already there through U, UL, I and UI. So completing the set with B, UB, S and US seems only logical and solves an existing (attention: buzzword ahead) ... *inconsistency*. ;)
> > 
> > To cut a long story short; if I added those suffixes and made a pull request would anyone be objected?
> 
> P.S.: There is no I or UI, just L and UL. Sorry for the confusion.

I experimented a bit with it and the modifications to DMD are mostly straight forward copy,paste,modify. But then I face palmed: 'b' is of course a valid digit in hex notation already, meaning it would always be counted as part of the hex number, and not as a suffix. That would be a bit ... inconvenient. :D

-- 
Marco

July 12, 2012
On 7/12/2012 2:42 AM, Marco Leise wrote:
> I understand that some of the examples have better alternatives. What I don't
> understand is why you term this as increased language complexity. This is not
> one of the "why not add" kind of requests. From my point of view the
> complexity is already there through U, UL, I and UI. So completing the set
> with B, UB, S and US seems only logical and solves an existing (attention:
> buzzword ahead) ... *inconsistency*. ;)
>
> To cut a long story short; if I added those suffixes and made a pull request
> would anyone be objected?

I'd object. I've been programming in C, C++ and D for 30 years now, and I use u and L suffixes way less than 1% of the time, and have simply never found a use for b or s suffixes.

I'm not convinced it solves a real problem.



July 12, 2012
On 12 July 2012 18:42, Marco Leise <Marco.Leise@gmx.de> wrote:
> Am Wed, 11 Jul 2012 22:58:07 +0200
> schrieb "bearophile" <bearophileHUGS@lycos.com>:
>
>> > => a = 5s;
>>
>> I read that as "5 seconds" :-(
>
> Me too, but then again "5l" could be read as 5 liters. I guess that is why the move is towards uppercase suffixes. 5S and 5L are not likely misread.

"L" is also an internationally-recognised symbol for litres.

http://physics.nist.gov/cuu/Units/outside.html

Personally, I think that if I need to care about the data size/maximum range of a value, I should be using a fixed-size data type rather than specifying it in the value. The language typically supports me in doing so without the need for prefixes except on rare occasions.

Geoff
July 13, 2012
Am Fri, 13 Jul 2012 08:31:31 +0900
schrieb Geoffrey Biggs <geoffrey.biggs@aist.go.jp>:

> Personally, I think that if I need to care about the data size/maximum range of a value, I should be using a fixed-size data type rather than specifying it in the value. The language typically supports me in doing so without the need for prefixes except on rare occasions.
> 
> Geoff

Please! This is a different story. You talk about declaring best fit data types, something that Delphi has a good go on for integral types (numbers and enums): type TPercentValue : 0 .. 100; // cannot assign a value outside that range

Just for the sake of clarification, the suffixes are there to disambiguate, since D - a little simplified - tries 32-bit types before 64-bit types and signed types before unsigned types; with no way to make a literal 8-bit or 16-bit for 'auto', function/method overloading or array type inference.

-- 
Marco

July 13, 2012
Am Thu, 12 Jul 2012 11:30:58 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 7/12/2012 2:42 AM, Marco Leise wrote:
> > I understand that some of the examples have better alternatives. What I don't understand is why you term this as increased language complexity. This is not one of the "why not add" kind of requests. From my point of view the complexity is already there through U, UL, I and UI. So completing the set with B, UB, S and US seems only logical and solves an existing (attention: buzzword ahead) ... *inconsistency*. ;)
> >
> > To cut a long story short; if I added those suffixes and made a pull request would anyone be objected?
> 
> I'd object. I've been programming in C, C++ and D for 30 years now, and I use u and L suffixes way less than 1% of the time, and have simply never found a use for b or s suffixes.
> 
> I'm not convinced it solves a real problem.

Alright, I'll stow it away as a little experiment. But consider, that especially C and to some extend C++ had less cases of ambiguous data types than D. And the point of new suffixes here is to avoid cast(byte) and cast(short) as a means to disambiguate, namely in the cases of: method overloads using both byte/int, array type inference and the 'auto' keyword.


C without name mangling for example wouldn't allow:

  void foo(ubyte x);
  void foo(int x);
  foo(128);
  // I'd often intuitively think, the ubyte version matches best

This is a typical case in general stream classes that offer overloaded write methods for every supported data type, e.g.:

  std.stream.EndianStream stream;
  stream.write(cast(ubyte) 0x01);
  // Have written 4 bytes instead of 1 in the past,
  // especially when the IDE shows the first matching overload as "write(byte x)" (Mono-D)

or with multiple constructors (here the earlier example from GtkD):

  // inside the Color class
  this(ubyte red, ubyte green, ubyte blue)
  {
      this();
      set8(red, green, blue);
  }
  this(guint16 red, guint16 green, guint16 blue)
  {
      this();
      set(red,green,blue);
  }
  // cannot call the 8-bit version without casts
  _black = new Color(cast(ubyte)0,cast(ubyte)0,cast(ubyte)0);
  _white = new Color(cast(ubyte)255,cast(ubyte)255,cast(ubyte)255);



An example with D's array type inference is:

  void unicodeTest(char[] code) { ... }
  unicodeTest("abc");
  unicodeTest(cast(char[]) [cast(ubyte) 0b11000111, cast(ubyte) 0b00111111]);
  // I think the second cast can be omitted here



The cases of 'auto' return or assignment can be worked around by not using auto and may be artificial. Yet it feels like auto is partially broken, because I cannot directly write down 8- and 16-bit integer literals like so:

  auto code(...)
  {
      if (...) return 42us;
      return 123us;
  }
  immutable Magic = 0x1234us;

-- 
Marco

July 13, 2012
A blog post about one of the Rust pointers, the "borrowed" ones:

http://smallcultfollowing.com/babysteps/blog/2012/07/10/borrowed-pointer-tutorial/

Bye,
bearophile
July 13, 2012
On 7/13/2012 3:21 AM, Marco Leise wrote:
> The cases of 'auto' return or assignment can be worked around by not using
> auto and may be artificial. Yet it feels like auto is partially broken,
> because I cannot directly write down 8- and 16-bit integer literals like so:
>
> auto code(...) { if (...) return 42us; return 123us; } immutable Magic =
> 0x1234us;

   auto code() { return cast(ushort)42; }

works fine. There isn't really a lack here, just some more typing. I just don't see the case coming up hardly at all.



July 17, 2012
Walter Bright:

>    auto code() { return cast(ushort)42; }
>
> works fine. There isn't really a lack here, just some more typing. I just don't see the case coming up hardly at all.

I have just found an example (reduced code):


import std.typecons;
void main() {
    alias Tuple!(ubyte[]) Tu;
    auto x1 = Tu([cast(ubyte)0]); // OK
    auto x2 = Tu([0]); // Error
}


D tuples are very strict.

Bye,
bearophile
July 17, 2012
On Friday, 13 July 2012 at 14:58:57 UTC, bearophile wrote:
> A blog post about one of the Rust pointers, the "borrowed" ones:
>
> http://smallcultfollowing.com/babysteps/blog/2012/07/10/borrowed-pointer-tutorial/
>
> Bye,
> bearophile

Rust is a much more interesting language than Go. At least they are taking some innovative paths and that's good.
July 17, 2012
On 07/17/2012 07:25 PM, bearophile wrote:
> Walter Bright:
>
>> auto code() { return cast(ushort)42; }
>>
>> works fine. There isn't really a lack here, just some more typing. I
>> just don't see the case coming up hardly at all.
>
> I have just found an example (reduced code):
>
>
> import std.typecons;
> void main() {
>     alias Tuple!(ubyte[]) Tu;
>     auto x1 = Tu([cast(ubyte)0]); // OK
>     auto x2 = Tu([0]); // Error
> }
>
>
> D tuples are very strict.
>
> Bye,
> bearophile

Looks like a bug in std.typecons.Tuple. That constructor shouldn't be
templated on the argument types.