www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD 2.064 changelog typo?

reply "Andrea Fontana" <nospam example.com> writes:
I was reading 2.064 changelog on website.
Check this:

template Tuple(T...) { alias Tuple = T; }

template isIntOrFloat(T)
{
     static if (is(T == int) || is(T == float))
         enum isIntOrFloat = true;
     else
         enum isIntOrFloat = true;
}

I guess the "else" branch should be " = false" rather than " = 
true";
Oct 29 2013
next sibling parent reply "Tourist" <gravatar gravatar.com> writes:
On Tuesday, 29 October 2013 at 09:43:23 UTC, Andrea Fontana wrote:

 I was reading 2.064 changelog on website.
 Check this:

 template Tuple(T...) { alias Tuple = T; }

 template isIntOrFloat(T)
 {
     static if (is(T == int) || is(T == float))
         enum isIntOrFloat = true;
     else
         enum isIntOrFloat = true;
 }

 I guess the "else" branch should be " = false" rather than " = 
 true";


Why the changelog for 2.064 is even available on dlang.org?
Oct 29 2013
parent reply "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Tuesday, 29 October 2013 at 09:44:36 UTC, Tourist wrote:

 On Tuesday, 29 October 2013 at 09:43:23 UTC, Andrea Fontana 
 wrote:

 I was reading 2.064 changelog on website.
 Check this:

 template Tuple(T...) { alias Tuple = T; }

 template isIntOrFloat(T)
 {
    static if (is(T == int) || is(T == float))
        enum isIntOrFloat = true;
    else
        enum isIntOrFloat = true;
 }

 I guess the "else" branch should be " = false" rather than " = 
 true";


 Why the changelog for 2.064 is even available on dlang.org?


I guess it's a good thing, it's available online. While looking 
through it, I also noticed that there are new functions 
'stripLeft/stripRight'. I believe it would be more consistent to 
call those stripFront/stripBack.
Oct 29 2013
next sibling parent "eles" <eles eles.com> writes:
On Tuesday, 29 October 2013 at 10:08:00 UTC, Sergei Nosov wrote:

 On Tuesday, 29 October 2013 at 09:44:36 UTC, Tourist wrote:

 On Tuesday, 29 October 2013 at 09:43:23 UTC, Andrea Fontana 
 wrote:


 I guess it's a good thing, it's available online. While looking 
 through it, I also noticed that there are new functions 
 'stripLeft/stripRight'. I believe it would be more consistent 
 to call those stripFront/stripBack.


+1
Oct 29 2013
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 29 October 2013 at 10:08:00 UTC, Sergei Nosov wrote:

 I guess it's a good thing, it's available online. While looking 
 through it, I also noticed that there are new functions 
 'stripLeft/stripRight'. I believe it would be more consistent 
 to call those stripFront/stripBack.


Yes, it would be, but they are also a generalization of the
eponymous string functions. Naming the new functions
"stripFront/stripBack" instead of "stripLeft/stripRight" would
itself be the more inconsistent.

For example:
//std.string.stripLeft
assert(stripLeft(" \tHello") == "Hello");
//std.algorithm.stripLeft(R, E)(R r, E e);
assert(stripLeft(" \tHello", ' ') == "\tHello");
//std.algorithm.stripLeft(alias pred, R)(R r);
assert(stripLeft!(Not!isLower)(" \tHello", ' ') == "ello");

But you make a valid point.
Oct 29 2013
parent reply "Nicolas Sicard" <dransic gmail.com> writes:
On Tuesday, 29 October 2013 at 20:56:02 UTC, monarch_dodra wrote:

 On Tuesday, 29 October 2013 at 10:08:00 UTC, Sergei Nosov wrote:

 I guess it's a good thing, it's available online. While 
 looking through it, I also noticed that there are new 
 functions 'stripLeft/stripRight'. I believe it would be more 
 consistent to call those stripFront/stripBack.


 Yes, it would be, but they are also a generalization of the
 eponymous string functions. Naming the new functions
 "stripFront/stripBack" instead of "stripLeft/stripRight" would
 itself be the more inconsistent.

 For example:
 //std.string.stripLeft
 assert(stripLeft(" \tHello") == "Hello");
 //std.algorithm.stripLeft(R, E)(R r, E e);
 assert(stripLeft(" \tHello", ' ') == "\tHello");
 //std.algorithm.stripLeft(alias pred, R)(R r);
 assert(stripLeft!(Not!isLower)(" \tHello", ' ') == "ello");

 But you make a valid point.


How do these string functions handle RTL languages? Even for 
strings, 'front' and 'back' might be more appropriate than 'left' 
and 'right'.
Oct 29 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 29 October 2013 at 21:14:39 UTC, Nicolas Sicard wrote:

 How do these string functions handle RTL languages? Even for 
 strings, 'front' and 'back' might be more appropriate than 
 'left' and 'right'.


Hum...

Now that you mention it, that is also a good point.  I feel they 
should indeed be called stripFront and stripBack.

 jmdavis,  andrejmitrovic: how would you feel about such a change?
Oct 29 2013
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/29/13, monarch_dodra <monarchdodra gmail.com> wrote:

 Now that you mention it, that is also a good point.  I feel they
 should indeed be called stripFront and stripBack.

  jmdavis,  andrejmitrovic: how would you feel about such a change?


It's funny that you should tag us two, I've asked about this here:

https://github.com/D-Programming-Language/phobos/pull/1201#issuecomment-17594047

Only got one reply, from JMD:

https://github.com/D-Programming-Language/phobos/pull/1201#issuecomment-17984774

And it wasn't talked about since. I think using the alias approach
would work, IOW std.array could use stripLeft/stripRight aliases to
stripFront/stripBack which would be in std.algorithm. There's
certainly nothing "left/right" about ranges.

Should we fix this before the release is made? What do Andrei and others think?
Oct 29 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/29/13 3:06 PM, Andrej Mitrovic wrote:

 On 10/29/13, monarch_dodra <monarchdodra gmail.com> wrote:

 Now that you mention it, that is also a good point.  I feel they
 should indeed be called stripFront and stripBack.

  jmdavis,  andrejmitrovic: how would you feel about such a change?


 It's funny that you should tag us two, I've asked about this here:

 https://github.com/D-Programming-Language/phobos/pull/1201#issuecomment-17594047

 Only got one reply, from JMD:

 https://github.com/D-Programming-Language/phobos/pull/1201#issuecomment-17984774

 And it wasn't talked about since. I think using the alias approach
 would work, IOW std.array could use stripLeft/stripRight aliases to
 stripFront/stripBack which would be in std.algorithm. There's
 certainly nothing "left/right" about ranges.

 Should we fix this before the release is made? What do Andrei and others think?


I'm okay with either choice, just not both. There's precedent in other 
languages for stripLeft and stripRight, but stripFront/Back are closer 
to D's terminology. I have a very mild preference for the latter.


Thanks,

Andrei
Oct 29 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 29 October 2013 at 23:39:13 UTC, Andrei Alexandrescu 
wrote:

 I'm okay with either choice, just not both. There's precedent 
 in other languages for stripLeft and stripRight, but 
 stripFront/Back are closer to D's terminology. I have a very 
 mild preference for the latter.


Funny you should say that, because my first reflex was to google 
search "stripLeft" to see if there was a precedent for it, and 
found nothing outside of dlang.

Who else uses "stripLeft" in their standard library?

I vote to change the names to stripFront/stripBack, and make 
deprecated aliases of stripLeft/stripRight in std.string.
Oct 30 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/13 2:14 AM, monarch_dodra wrote:

 On Tuesday, 29 October 2013 at 23:39:13 UTC, Andrei Alexandrescu wrote:

 I'm okay with either choice, just not both. There's precedent in other
 languages for stripLeft and stripRight, but stripFront/Back are closer
 to D's terminology. I have a very mild preference for the latter.


 Funny you should say that, because my first reflex was to google search
 "stripLeft" to see if there was a precedent for it, and found nothing
 outside of dlang.

 Who else uses "stripLeft" in their standard library?

 I vote to change the names to stripFront/stripBack, and make deprecated
 aliases of stripLeft/stripRight in std.string.


I could have sworn googling for them would return a bunch of languages 
and libraries. I could only find on Haskell library. But then I could 
only find one library using stringFront/Back.

Since we've already had stripLeft/Back for strings, I vote to stop this 
changing names nonsense. Either pair is good, and we've voted for one 
already.


Andrei
Oct 30 2013
next sibling parent Philip Miess <philip.Miess yahoo.com> writes:
On Wed, 30 Oct 2013 07:56:04 -0700, Andrei Alexandrescu wrote:


 On 10/30/13 2:14 AM, monarch_dodra wrote:

 On Tuesday, 29 October 2013 at 23:39:13 UTC, Andrei Alexandrescu wrote:

 I'm okay with either choice, just not both. There's precedent in other
 languages for stripLeft and stripRight, but stripFront/Back are closer
 to D's terminology. I have a very mild preference for the latter.


 Funny you should say that, because my first reflex was to google search
 "stripLeft" to see if there was a precedent for it, and found nothing
 outside of dlang.

 Who else uses "stripLeft" in their standard library?

 I vote to change the names to stripFront/stripBack, and make deprecated
 aliases of stripLeft/stripRight in std.string.


 
 I could have sworn googling for them would return a bunch of languages
 and libraries. I could only find on Haskell library. But then I could
 only find one library using stringFront/Back.
 
 Since we've already had stripLeft/Back for strings, I vote to stop this
 changing names nonsense. Either pair is good, and we've voted for one
 already.
 
 
 Andrei


Left &  Right or L & R are apparently used in VB6 like languages, TCL, 
Python, Delphi & TSQL

https://en.wikipedia.org/wiki/Trimming_(computer_programming)

Phil
Oct 30 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, October 30, 2013 07:56:04 Andrei Alexandrescu wrote:

 On 10/30/13 2:14 AM, monarch_dodra wrote:

 On Tuesday, 29 October 2013 at 23:39:13 UTC, Andrei Alexandrescu wrote:

 I'm okay with either choice, just not both. There's precedent in other
 languages for stripLeft and stripRight, but stripFront/Back are closer
 to D's terminology. I have a very mild preference for the latter.


 
 Funny you should say that, because my first reflex was to google search
 "stripLeft" to see if there was a precedent for it, and found nothing
 outside of dlang.
 
 Who else uses "stripLeft" in their standard library?
 
 I vote to change the names to stripFront/stripBack, and make deprecated
 aliases of stripLeft/stripRight in std.string.


 
 I could have sworn googling for them would return a bunch of languages
 and libraries. I could only find on Haskell library. But then I could
 only find one library using stringFront/Back.
 
 Since we've already had stripLeft/Back for strings, I vote to stop this
 changing names nonsense. Either pair is good, and we've voted for one
 already.


They were originally stripl and stripr, so googling may find those more easily. 
But that didn't follow our naming conventions, so we changed it when we tried 
to make std.string consistent with our naming scheme. And stripLeft and 
stripRight are what stripl and stripr stood for, so that's how they got those 
names.

stripFront and stripBack would arguably be better names for ranges in general, 
but given that we already have stripLeft and stripRight, I agree that we 
should just leave it as-is rather than having to deal with renaming 
std.string.stripLeft and std.string.stripRight yet again. stripLeft and 
stripRight might not be quite as nice names for range-based stuff, but they 
work. We can argue names all day, and I don't think that there's enough gain 
in this case to be worth the change. If the original names had followed our 
naming conventions properly, they likely never would have been renamed in the 
first place. That's the primary reason that we've renamed stuff, and that's not 
the case here.

- Jonathan M Davis
Oct 30 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-29 10:43, Andrea Fontana wrote:

 I was reading 2.064 changelog on website.
 Check this:

 template Tuple(T...) { alias Tuple = T; }

 template isIntOrFloat(T)
 {
      static if (is(T == int) || is(T == float))
          enum isIntOrFloat = true;
      else
          enum isIntOrFloat = true;
 }

 I guess the "else" branch should be " = false" rather than " = true";


Or just:

template isIntOrFloat(T)
{
     enum isIntOrFloat = is(T == int) || is(T == float)
}

-- 
/Jacob Carlborg
Oct 29 2013
parent reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Tuesday, 29 October 2013 at 10:26:13 UTC, Jacob Carlborg wrote:

 On 2013-10-29 10:43, Andrea Fontana wrote:

 I was reading 2.064 changelog on website.
 Check this:

 template Tuple(T...) { alias Tuple = T; }

 template isIntOrFloat(T)
 {
     static if (is(T == int) || is(T == float))
         enum isIntOrFloat = true;
     else
         enum isIntOrFloat = true;
 }

 I guess the "else" branch should be " = false" rather than " = 
 true";


 Or just:

 template isIntOrFloat(T)
 {
     enum isIntOrFloat = is(T == int) || is(T == float)
 }


Didn't we get the shorthand enum template syntax in this release?

enum isInOrFloat(T) = is(T == int) || is(T == float)
Oct 29 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 29 October 2013 12:13, Rene Zwanenburg <renezwanenburg gmail.com> wrote:

 On Tuesday, 29 October 2013 at 10:26:13 UTC, Jacob Carlborg wrote:

 On 2013-10-29 10:43, Andrea Fontana wrote:

 I was reading 2.064 changelog on website.
 Check this:

 template Tuple(T...) { alias Tuple = T; }

 template isIntOrFloat(T)
 {
     static if (is(T == int) || is(T == float))
         enum isIntOrFloat = true;
     else
         enum isIntOrFloat = true;
 }

 I guess the "else" branch should be " = false" rather than " = true";


 Or just:

 template isIntOrFloat(T)
 {
     enum isIntOrFloat = is(T == int) || is(T == float)
 }



 Didn't we get the shorthand enum template syntax in this release?

 enum isInOrFloat(T) = is(T == int) || is(T == float)


In 2.063?  No we didn't.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 29 2013
parent "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Tuesday, 29 October 2013 at 14:15:27 UTC, Iain Buclaw wrote:

 On 29 October 2013 12:13, Rene Zwanenburg 
 <renezwanenburg gmail.com> wrote:

 Didn't we get the shorthand enum template syntax in this 
 release?

 enum isInOrFloat(T) = is(T == int) || is(T == float)


 In 2.063?  No we didn't.


Oops, I didn't notice the quoted code came from the section 
describing the new syntax. Never mind :)
Oct 29 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/29/13, Andrea Fontana <nospam example.com> wrote:

 I guess the "else" branch should be " = false" rather than " =
 true";


It was fixed:
https://github.com/D-Programming-Language/dlang.org/pull/403

On 10/29/13, Tourist <gravatar gravatar.com> wrote:

 Why the changelog for 2.064 is even available on dlang.org?


Because of a great organization.
Oct 29 2013