• bearophile (82/87) Jun 26 2014 For people that are not following closely what's happening in
• Shammah Chancellor (3/134) Jun 26 2014 Some of those fix some very annoying and long standing bugs. Whoot.
• Rene Zwanenburg (4/16) Jun 26 2014 Yup, thanks for posting this here, those are all very exciting
• Meta (3/6) Jun 26 2014 Won't some people, especially those coming from C++, mistake this
• bearophile (8/12) Jun 26 2014 C/C++ const is very different from D one (transitive), so C++
• H. S. Teoh via Digitalmars-d (19/81) Jun 26 2014 This is probably because without -D, the entire ddoc code doesn't even
• bearophile (8/11) Jun 26 2014 auto is used to use the type of the value on the right. But "a =>
• H. S. Teoh via Digitalmars-d (12/26) Jun 26 2014 [...]
• Jacob Carlborg (4/9) Jun 27 2014 __traits(getUnitTests) also depends on a compiler flag (-unittest).
• Meta (4/11) Jun 26 2014 So if this pull request gets merged, should we deprecate
• bearophile (4/7) Jun 26 2014 perhaps unaryFun is to convert the strings like q{a * a}.
• Meta (3/10) Jun 26 2014 There has been discussion before about doing away with string
• bearophile (5/7) Jun 26 2014 If they get deprecated I will have to manually fix a _ton_ of
• Meta (4/11) Jun 26 2014 I guess instead of deprecate, I guess I really mean just "phase
• H. S. Teoh via Digitalmars-d (6/21) Jun 26 2014 Care to submit a PR to remove mentions of string lambdas from the Phobos
• Tofu Ninja (6/9) Jun 26 2014 I feel like this is a bad idea, we shouldn't be deleting
• Meta (7/16) Jun 26 2014 I'm on the fence. String lambdas are about as concise as is
• Meta (3/6) Jun 26 2014 Sure, as soon as it gets merged.
• Meta (2/8) Jun 26 2014 I mean the change to allow `alias sqr = a => a * a`.
• Brad Anderson (6/29) Jun 26 2014 I took a stab at this long ago. A dmd bug with closures prevented
• Jonathan M Davis via Digitalmars-d (6/19) Jun 27 2014 The major problem that still needs to be fixed with non-string lambdas i...
• H. S. Teoh via Digitalmars-d (14/34) Jun 27 2014 [...]
• Meta (4/6) Jun 27 2014 I've yet to see a pull request for it, so I'd assume that there
• Sean Kelly (15/18) Jun 26 2014 I'm pretty biased, but am quite excited about:
• bearophile (6/14) Jun 26 2014 Do you need the "new" there? Is that a heap-allocated class
• Sean Kelly (3/15) Jun 26 2014 I could hide the "new" somehow, but you're effectively creating a
• Orvid King (6/9) Jun 26 2014 While we're on the subject, I've been meaning to make a post about it,
• Steven Schveighoffer (3/12) Jun 26 2014 Link? There are many PRs...
• H. S. Teoh via Digitalmars-d (7/21) Jun 26 2014 [...]
• Jesse Phillips (8/8) Jun 26 2014 Here are some of the items I voted on that I see have been
• Kagamin (5/14) Jun 27 2014 It can share syntax with explicit array operations:
• Lionello Lunesu (12/21) Jun 29 2014 I feel I did address his points, but more importantly there was not much...
• bearophile (5/11) Jun 30 2014 OK. But the other idea (value range for if/then, and for pre/post
• Lionello Lunesu (7/18) Jun 30 2014 I'm actively developing that in my if-else-range branch. It's also part

"bearophile" <bearophileHUGS lycos.com> writes:

For people that are not following closely what's happening in 
GitHub, there are some nice or very nice patches waiting to be 
fixed and/or accepted, among the last ones:

--------------------

This proposes a __traits(documentation, expr):
https://github.com/D-Programming-Language/dmd/pull/3531

Something similar is used in Python and Lisp, it allows to 
introspect the comments. It's useful for various generative 
purposes.

One quirk of this implementation, that I am not sure about:

Comments will only be available if DMD is invoked with the "-D" 
flag. If no comment is available for expr, __traits(comment, 
expr) evaluates to the empty string.<

--------------------

Optional monitors for class instances, including a fallback:
https://github.com/D-Programming-Language/dmd/pull/3547

It was discussed in this newsgroup too. Beside the little save in 
memory (probably small), monitors today are not much appreciated. 
Andrei seemed to agree with this idea.

--------------------

https://github.com/D-Programming-Language/dmd/pull/3615

Will allow very handy, more DRY and less bug-prone like this:

// static array type
int[$]   a1 = [1,2];    // int[2]
auto[$]  a2 = [3,4,5];  // int[3]
const[$] a3 = [6,7,8];  // const(int[3])

// dynamic array type
immutable[] a4 = [1,2];    // immutable(int)[]
shared[]    a5 = [3,4,5];  // shared(int)[]
// partially specified part is unqualified.

// pointer type
auto*  p1 = new int(3);  // int*
const* p2 = new int(3);  // const(int)*

// mixing
auto[][$] x1 = [[1,2,3],[4,5]];  // int[][2]
shared*[$] x2 = [new int(1), new int(2)];  // shared(int)*[2]


A comment by Walter:

My reservation on this is I keep thinking there must be a better 
way than [$].<

--------------------

https://github.com/D-Programming-Language/dmd/pull/3638

Allows to write code like:


void main() {
     import std.algorithm;
     alias sqr = a => a ^^ 2;
     auto r = [1, 2, 3].map!sqr;
}


Currently you need to write:

alias F(alias f) = f;
void main() {
     import std.algorithm;
     alias sqr = F!(a => a ^^ 2);
     auto r = [1, 2, 3].map!sqr;
}

--------------------

https://github.com/D-Programming-Language/dmd/pull/3679

This introduces __traits(valueRange, expr), and I think it 
introduces range values to the ?: expressions too.

The __traits(valueRange, expr) is meant to be useful for 
debugging range values, that is meant to be improved in future. 
Currently this patch seems stalled because Lionello seems to not 
provide few small things Walter has asked.

--------------------

https://github.com/D-Programming-Language/dmd/pull/3680


It should fix this bug:

void main() {
     int[int][int] a1 = cast()[1: [2: 3]]; // workaround
     int[int][int] a2 =       [1: [2: 3]]; // error
}


And will allow you to write:

void main() {
     import std.bigint;
     BigInt[] data = [-5, 6, 9];
}


Currently in D you have write this:

void main() {
     import std.bigint;
     auto data = [BigInt(-5), BigInt(6), BigInt(9)];
}


Or this (writing -5.BigInt is generally not a good idea):

void main() {
     import std.bigint;
     auto data = [BigInt(-5), 6.BigInt, 9.BigInt];
}

--------------------

Bye,
bearophile

Shammah Chancellor <anonymous coward.com> writes:

On 2014-06-26 10:38:53 +0000, bearophile said:

 For people that are not following closely what's happening in GitHub, 
 there are some nice or very nice patches waiting to be fixed and/or 
 accepted, among the last ones:
 
 --------------------
 
 This proposes a __traits(documentation, expr):
 https://github.com/D-Programming-Language/dmd/pull/3531
 
 Something similar is used in Python and Lisp, it allows to introspect 
 the comments. It's useful for various generative purposes.
 
 One quirk of this implementation, that I am not sure about:
 
 Comments will only be available if DMD is invoked with the "-D" flag. 
 If no comment is available for expr, __traits(comment, expr) evaluates 
 to the empty string.<

 
 --------------------
 
 Optional monitors for class instances, including a fallback:
 https://github.com/D-Programming-Language/dmd/pull/3547
 
 It was discussed in this newsgroup too. Beside the little save in 
 memory (probably small), monitors today are not much appreciated. 
 Andrei seemed to agree with this idea.
 
 --------------------
 
 https://github.com/D-Programming-Language/dmd/pull/3615
 
 Will allow very handy, more DRY and less bug-prone like this:
 
 // static array type
 int[$]   a1 = [1,2];    // int[2]
 auto[$]  a2 = [3,4,5];  // int[3]
 const[$] a3 = [6,7,8];  // const(int[3])
 
 // dynamic array type
 immutable[] a4 = [1,2];    // immutable(int)[]
 shared[]    a5 = [3,4,5];  // shared(int)[]
 // partially specified part is unqualified.
 
 // pointer type
 auto*  p1 = new int(3);  // int*
 const* p2 = new int(3);  // const(int)*
 
 // mixing
 auto[][$] x1 = [[1,2,3],[4,5]];  // int[][2]
 shared*[$] x2 = [new int(1), new int(2)];  // shared(int)*[2]
 
 
 A comment by Walter:
 
 My reservation on this is I keep thinking there must be a better way than [$].<

 
 --------------------
 
 https://github.com/D-Programming-Language/dmd/pull/3638
 
 Allows to write code like:
 
 
 void main() {
      import std.algorithm;
      alias sqr = a => a ^^ 2;
      auto r = [1, 2, 3].map!sqr;
 }
 
 
 Currently you need to write:
 
 alias F(alias f) = f;
 void main() {
      import std.algorithm;
      alias sqr = F!(a => a ^^ 2);
      auto r = [1, 2, 3].map!sqr;
 }
 
 --------------------
 
 https://github.com/D-Programming-Language/dmd/pull/3679
 
 This introduces __traits(valueRange, expr), and I think it introduces 
 range values to the ?: expressions too.
 
 The __traits(valueRange, expr) is meant to be useful for debugging 
 range values, that is meant to be improved in future. Currently this 
 patch seems stalled because Lionello seems to not provide few small 
 things Walter has asked.
 
 --------------------
 
 https://github.com/D-Programming-Language/dmd/pull/3680
 
 
 It should fix this bug:
 
 void main() {
      int[int][int] a1 = cast()[1: [2: 3]]; // workaround
      int[int][int] a2 =       [1: [2: 3]]; // error
 }
 
 
 And will allow you to write:
 
 void main() {
      import std.bigint;
      BigInt[] data = [-5, 6, 9];
 }
 
 
 Currently in D you have write this:
 
 void main() {
      import std.bigint;
      auto data = [BigInt(-5), BigInt(6), BigInt(9)];
 }
 
 
 Or this (writing -5.BigInt is generally not a good idea):
 
 void main() {
      import std.bigint;
      auto data = [BigInt(-5), 6.BigInt, 9.BigInt];
 }
 
 --------------------
 
 Bye,
 bearophile


Some of those fix some very annoying and long standing bugs.   Whoot.

-Shammah

"Rene Zwanenburg" <renezwanenburg gmail.com> writes:

On Thursday, 26 June 2014 at 10:52:22 UTC, Shammah Chancellor 
wrote:
 On 2014-06-26 10:38:53 +0000, bearophile said:

 For people that are not following closely what's happening in 
 GitHub, there are some nice or very nice patches waiting to be 
 fixed and/or accepted, among the last ones:
 
 ...
 
 Bye,
 bearophile


 Some of those fix some very annoying and long standing bugs.   
 Whoot.

 -Shammah

Yup, thanks for posting this here, those are all very exciting 
changes. I've really been looking forward to some of them!

"Meta" <jared771 gmail.com> writes:

On Thursday, 26 June 2014 at 10:38:54 UTC, bearophile wrote:
 // pointer type
 auto*  p1 = new int(3);  // int*
 const* p2 = new int(3);  // const(int)*

Won't some people, especially those coming from C++, mistake this 
for being syntax to create a constant pointer to a mutable int?

"bearophile" <bearophileHUGS lycos.com> writes:

Meta:

 const* p2 = new int(3);  // const(int)*

 Won't some people, especially those coming from C++, mistake 
 this for being syntax to create a constant pointer to a mutable 
 int?

C/C++ const is very different from D one (transitive), so C++ 
programmers must learn the differences.

If a C++ mistakes that for a constant pointer to a mutable int, 
and tries to modify the int, she receives a compilation error. So 
this doesn't seem able to cause bugs or significant problems.

Bye,
bearophile

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

On Thu, Jun 26, 2014 at 10:38:53AM +0000, bearophile via Digitalmars-d wrote:
[...]
 --------------------
 
 This proposes a __traits(documentation, expr):
 https://github.com/D-Programming-Language/dmd/pull/3531
 
 Something similar is used in Python and Lisp, it allows to introspect
 the comments. It's useful for various generative purposes.
 
 One quirk of this implementation, that I am not sure about:
 
Comments will only be available if DMD is invoked with the "-D" flag.
If no comment is available for expr, __traits(comment, expr)
evaluates to the empty string.<


This is probably because without -D, the entire ddoc code doesn't even
run (which probably saves on compilation time), and comments are not
kept by the parser/lexer, so by the time the compiler evaluates
__traits(comment...), it doesn't know how to retrieve the comments
anymore.


[...]
 --------------------
 
 https://github.com/D-Programming-Language/dmd/pull/3615
 
 Will allow very handy, more DRY and less bug-prone like this:
 
 // static array type
 int[$]   a1 = [1,2];    // int[2]
 auto[$]  a2 = [3,4,5];  // int[3]
 const[$] a3 = [6,7,8];  // const(int[3])
 
 // dynamic array type
 immutable[] a4 = [1,2];    // immutable(int)[]
 shared[]    a5 = [3,4,5];  // shared(int)[]
 // partially specified part is unqualified.
 
 // pointer type
 auto*  p1 = new int(3);  // int*
 const* p2 = new int(3);  // const(int)*
 
 // mixing
 auto[][$] x1 = [[1,2,3],[4,5]];  // int[][2]
 shared*[$] x2 = [new int(1), new int(2)];  // shared(int)*[2]

I like this very much. I hope it will get merged in one form or another
eventually.


 A comment by Walter:
 
My reservation on this is I keep thinking there must be a better way
than [$].<


Is the only objection one about syntax? Surely professional bikeshedders
like us can easily come up with more palatable syntaxes? ;-)


 --------------------
 
 https://github.com/D-Programming-Language/dmd/pull/3638
 
 Allows to write code like:
 
 
 void main() {
     import std.algorithm;
     alias sqr = a => a ^^ 2;
     auto r = [1, 2, 3].map!sqr;
 }
 
 
 Currently you need to write:
 
 alias F(alias f) = f;
 void main() {
     import std.algorithm;
     alias sqr = F!(a => a ^^ 2);
     auto r = [1, 2, 3].map!sqr;
 }

[...]

What's wrong with just writing auto?

	auto sqr = a => a^^2;
	auto r = [1,2,3].map!sqr;


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system
vulnerabilities cannot touch Linux---is priceless. -- Frustrated system
administrator.

"bearophile" <bearophileHUGS lycos.com> writes:

H. S. Teoh:

 What's wrong with just writing auto?

 	auto sqr = a => a^^2;
 	auto r = [1,2,3].map!sqr;

auto is used to use the type of the value on the right. But "a => 
a^^2" is not a value, it can't be assigned to a variable, because 
it's not a lambda.

To use auto you need to give a type, creating a lambda:

auto sqr = (int a) => a ^^ 2;

Bye,
bearophile

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

On Thu, Jun 26, 2014 at 02:45:05PM +0000, bearophile via Digitalmars-d wrote:
 H. S. Teoh:
 
What's wrong with just writing auto?

	auto sqr = a => a^^2;
	auto r = [1,2,3].map!sqr;

 
 auto is used to use the type of the value on the right. But "a =>
 a^^2" is not a value, it can't be assigned to a variable, because it's
 not a lambda.
 
 To use auto you need to give a type, creating a lambda:
 
 auto sqr = (int a) => a ^^ 2;

[...]

Oh I see, you want the argument type to be generic?

This works with dmd git HEAD:

	import std.algorithm : map;
	static sqr(A)(A a) { return a^^2; }
	auto r1 = [1,2,3].map!sqr;
	auto r2 = [1.0, 2.0, 3.0].map!sqr;

It's a little more verbose, though.


T

-- 
The easy way is the wrong way, and the hard way is the stupid way. Pick one.

Jacob Carlborg <doob me.com> writes:

On 2014-06-26 16:37, H. S. Teoh via Digitalmars-d wrote:

 This is probably because without -D, the entire ddoc code doesn't even
 run (which probably saves on compilation time), and comments are not
 kept by the parser/lexer, so by the time the compiler evaluates
 __traits(comment...), it doesn't know how to retrieve the comments
 anymore.

__traits(getUnitTests) also depends on a compiler flag (-unittest).

-- 
/Jacob Carlborg

"Meta" <jared771 gmail.com> writes:

On Thursday, 26 June 2014 at 10:38:54 UTC, bearophile wrote:
 https://github.com/D-Programming-Language/dmd/pull/3638

 Allows to write code like:


 void main() {
     import std.algorithm;
     alias sqr = a => a ^^ 2;
     auto r = [1, 2, 3].map!sqr;
 }

So if this pull request gets merged, should we deprecate 
std.functional.unaryFun and binaryFun? I don't see much need for 
them with this pull merged.

"bearophile" <bearophileHUGS lycos.com> writes:

Meta:

 So if this pull request gets merged, should we deprecate 
 std.functional.unaryFun and binaryFun? I don't see much need 
 for them with this pull merged.

perhaps unaryFun is to convert the strings like q{a * a}.

Bye,
bearophile

"Meta" <jared771 gmail.com> writes:

On Thursday, 26 June 2014 at 16:05:24 UTC, bearophile wrote:
 Meta:

 So if this pull request gets merged, should we deprecate 
 std.functional.unaryFun and binaryFun? I don't see much need 
 for them with this pull merged.

 perhaps unaryFun is to convert the strings like q{a * a}.

 Bye,
 bearophile

There has been discussion before about doing away with string 
lambdas. Maybe this is a good time to do that.

"bearophile" <bearophileHUGS lycos.com> writes:

Meta:

 There has been discussion before about doing away with string 
 lambdas. Maybe this is a good time to do that.

If they get deprecated I will have to manually fix a _ton_ of 
code :-)

Bye,
bearophile

"Meta" <jared771 gmail.com> writes:

On Thursday, 26 June 2014 at 17:26:02 UTC, bearophile wrote:
 Meta:

 There has been discussion before about doing away with string 
 lambdas. Maybe this is a good time to do that.

 If they get deprecated I will have to manually fix a _ton_ of 
 code :-)

 Bye,
 bearophile

I guess instead of deprecate, I guess I really mean just "phase 
out". Undocument these templates and discourage their use, but 
don't actually deprecate them.

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

On Thu, Jun 26, 2014 at 05:45:23PM +0000, Meta via Digitalmars-d wrote:
 On Thursday, 26 June 2014 at 17:26:02 UTC, bearophile wrote:
Meta:

There has been discussion before about doing away with string
lambdas.  Maybe this is a good time to do that.

If they get deprecated I will have to manually fix a _ton_ of code
:-)

Bye,
bearophile

 
 I guess instead of deprecate, I guess I really mean just "phase out".
 Undocument these templates and discourage their use, but don't
 actually deprecate them.

Care to submit a PR to remove mentions of string lambdas from the Phobos
docs? They're still all over the place.


T

-- 
Amateurs built the Ark; professionals built the Titanic.

"Tofu Ninja" <emmons0 purdue.edu> writes:

On Thursday, 26 June 2014 at 18:55:38 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 Care to submit a PR to remove mentions of string lambdas from 
 the Phobos
 docs? They're still all over the place.

I feel like this is a bad idea, we shouldn't be deleting 
documentation. It will just end up causing more problems. Any 
ways, what is so inherently bad about them? Personally for vary 
small things I prefer string lambdas as they just look nicer.

"Meta" <jared771 gmail.com> writes:

On Thursday, 26 June 2014 at 19:30:38 UTC, Tofu Ninja wrote:
 On Thursday, 26 June 2014 at 18:55:38 UTC, H. S. Teoh via 
 Digitalmars-d wrote:
 Care to submit a PR to remove mentions of string lambdas from 
 the Phobos
 docs? They're still all over the place.

 I feel like this is a bad idea, we shouldn't be deleting 
 documentation. It will just end up causing more problems. Any 
 ways, what is so inherently bad about them? Personally for vary 
 small things I prefer string lambdas as they just look nicer.

I'm on the fence. String lambdas are about as concise as is 
syntactically possible, although q{a * b} looks a bit ugly, and 
"a * b" doesn't highlight properly in editors. Also, I think they 
will confuse newcomers. It's really weird that [1, 2, 3].map!"a + 
1" turns the passed string into a function, and extremely 
confusing if you haven't read the documentation.

"Meta" <jared771 gmail.com> writes:

On Thursday, 26 June 2014 at 18:55:38 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 Care to submit a PR to remove mentions of string lambdas from 
 the Phobos
 docs? They're still all over the place.

Sure, as soon as it gets merged.

"Meta" <jared771 gmail.com> writes:

On Thursday, 26 June 2014 at 20:36:01 UTC, Meta wrote:
 On Thursday, 26 June 2014 at 18:55:38 UTC, H. S. Teoh via 
 Digitalmars-d wrote:
 Care to submit a PR to remove mentions of string lambdas from 
 the Phobos
 docs? They're still all over the place.

 Sure, as soon as it gets merged.

I mean the change to allow `alias sqr = a => a * a`.

"Brad Anderson" <eco gnuk.net> writes:

On Thursday, 26 June 2014 at 18:55:38 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Thu, Jun 26, 2014 at 05:45:23PM +0000, Meta via 
 Digitalmars-d wrote:
 On Thursday, 26 June 2014 at 17:26:02 UTC, bearophile wrote:
Meta:

There has been discussion before about doing away with string
lambdas.  Maybe this is a good time to do that.

If they get deprecated I will have to manually fix a _ton_ of 
code
:-)

Bye,
bearophile

 
 I guess instead of deprecate, I guess I really mean just 
 "phase out".
 Undocument these templates and discourage their use, but don't
 actually deprecate them.

 Care to submit a PR to remove mentions of string lambdas from 
 the Phobos
 docs? They're still all over the place.


 T

I took a stab at this long ago. A dmd bug with closures prevented 
it from getting merged though. I believe the dmd bug has been 
fixed so someone could give this another go.

https://github.com/D-Programming-Language/phobos/pull/707

Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Thursday, June 26, 2014 17:45:23 Meta via Digitalmars-d wrote:
 On Thursday, 26 June 2014 at 17:26:02 UTC, bearophile wrote:
 Meta:
 There has been discussion before about doing away with string
 lambdas. Maybe this is a good time to do that.

 If they get deprecated I will have to manually fix a _ton_ of
 code :-)

 Bye,
 bearophile

 I guess instead of deprecate, I guess I really mean just "phase
 out". Undocument these templates and discourage their use, but
 don't actually deprecate them.

The major problem that still needs to be fixed with non-string lambdas is the
ability to compare them. Right now, as I understand it, the same non-string
lambda doesn't even result in the same template instantiation. String lambdas
don't have that problem.

- Jonathan M Davis

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

On Fri, Jun 27, 2014 at 03:24:36PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
 On Thursday, June 26, 2014 17:45:23 Meta via Digitalmars-d wrote:
 On Thursday, 26 June 2014 at 17:26:02 UTC, bearophile wrote:
 Meta:
 There has been discussion before about doing away with string
 lambdas. Maybe this is a good time to do that.

 If they get deprecated I will have to manually fix a _ton_ of
 code :-)

 Bye,
 bearophile

 I guess instead of deprecate, I guess I really mean just "phase
 out". Undocument these templates and discourage their use, but
 don't actually deprecate them.

 
 The major problem that still needs to be fixed with non-string lambdas
 is the ability to compare them. Right now, as I understand it, the
 same non-string lambda doesn't even result in the same template
 instantiation. String lambdas don't have that problem.

[...]

String lambda comparison is moot: "a<b" and "a < b" do not compare
equal. But at least, calling find!"a<b" multiple times will reuse the
same instantiation, whereas using lambdas will not. So at the very least
we need to fix lambda comparison so that identical lambdas will compare
equal.

Andrei talked about various schemes of lambda comparison before, and I
think the consensus was that some sort of hash function on the lambda's
AST would be most practical, and easiest to implement. I don't know if
any further progress has been made since then, though.


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what
you have now either.

"Meta" <jared771 gmail.com> writes:

On Friday, 27 June 2014 at 22:31:57 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 I don't know if any further progress has been made since then, 
 though.

I've yet to see a pull request for it, so I'd assume that there 
hasn't.

"Sean Kelly" <sean invisibleduck.org> writes:

On Thursday, 26 June 2014 at 10:38:54 UTC, bearophile wrote:
 For people that are not following closely what's happening in 
 GitHub, there are some nice or very nice patches waiting to be 
 fixed and/or accepted

I'm pretty biased, but am quite excited about:

https://github.com/D-Programming-Language/phobos/pull/1910

Which allows:

void main() {
      auto r = new Generator!string({
          yield("the");
          yield("quick");
          yield("brown");
          yield("fox");
      });

      foreach (e; r) {
          writeln(e);
      }
}

"bearophile" <bearophileHUGS lycos.com> writes:

Sean Kelly:

 I'm pretty biased, but am quite excited about:

Mine was only a partial list :-)


 void main() {
      auto r = new Generator!string({
          yield("the");
          yield("quick");
          yield("brown");
          yield("fox");
      });

Do you need the "new" there? Is that a heap-allocated class 
instance? Is that r Generator working at module scope too?

Bye,
bearophile

"Sean Kelly" <sean invisibleduck.org> writes:

On Thursday, 26 June 2014 at 19:42:46 UTC, bearophile wrote:
 Sean Kelly:

 I'm pretty biased, but am quite excited about:

 Mine was only a partial list :-)


 void main() {
     auto r = new Generator!string({
         yield("the");
         yield("quick");
         yield("brown");
         yield("fox");
     });

 Do you need the "new" there? Is that a heap-allocated class 
 instance? Is that r Generator working at module scope too?

I could hide the "new" somehow, but you're effectively creating a
Fiber so allocation has to happen somewhere.

Orvid King <blah38621 gmail.com> writes:

On 6/26/2014 5:38 AM, bearophile wrote:
 For people that are not following closely what's happening in GitHub,
 there are some nice or very nice patches waiting to be fixed and/or
 accepted, among the last ones:

While we're on the subject, I've been meaning to make a post about it, 
but just hadn't gotten around to it, there is a PR that I made a little 

really is a 6 year old bug that is fixed by removing an if statement), 
but has yet to actually be reviewed.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 26 Jun 2014 16:21:24 -0400, Orvid King <blah38621 gmail.com> wrote:

 On 6/26/2014 5:38 AM, bearophile wrote:
 For people that are not following closely what's happening in GitHub,
 there are some nice or very nice patches waiting to be fixed and/or
 accepted, among the last ones:

 While we're on the subject, I've been meaning to make a post about it,  
 but just hadn't gotten around to it, there is a PR that I made a little  

 really is a 6 year old bug that is fixed by removing an if statement),  
 but has yet to actually be reviewed.

Link? There are many PRs...

-Steve

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

On Thu, Jun 26, 2014 at 04:27:16PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
 On Thu, 26 Jun 2014 16:21:24 -0400, Orvid King <blah38621 gmail.com> wrote:
 
On 6/26/2014 5:38 AM, bearophile wrote:
For people that are not following closely what's happening in
GitHub, there are some nice or very nice patches waiting to be fixed
and/or accepted, among the last ones:

While we're on the subject, I've been meaning to make a post about
it, but just hadn't gotten around to it, there is a PR that I made a

typo, it really is a 6 year old bug that is fixed by removing an if
statement), but has yet to actually be reviewed.

 
 Link? There are many PRs...

[...]

Apparently:

https://github.com/D-Programming-Language/dmd/pull/3483


T

-- 
Not all rumours are as misleading as this one.

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

Here are some of the items I voted on that I see have been 
resolved:

https://issues.dlang.org/show_bug.cgi?id=1528
overloading template and non-template functions

https://issues.dlang.org/show_bug.cgi?id=5700
Allow dup in nothrow functions

https://issues.dlang.org/show_bug.cgi?id=5893
Allow simple aliases for operator overloading

"Kagamin" <spam here.lot> writes:

On Thursday, 26 June 2014 at 10:38:54 UTC, bearophile wrot
 https://github.com/D-Programming-Language/dmd/pull/3615

 Will allow very handy, more DRY and less bug-prone like this:

 // static array type
 int[$]   a1 = [1,2];    // int[2]
 auto[$]  a2 = [3,4,5];  // int[3]
 const[$] a3 = [6,7,8];  // const(int[3])

 A comment by Walter:

My reservation on this is I keep thinking there must be a 
better way than [$].<


It can share syntax with explicit array operations:
int[*] a1 = [1,2]; // int[2]
int[*] a2 = [3,4]; // int[2]
a1[*] = a2[*]; // copy a2 to a1

Lionello Lunesu <lionello lunesu.remove.com> writes:

On 26/06/14 18:38, bearophile wrote:
 --------------------

 https://github.com/D-Programming-Language/dmd/pull/3679

 This introduces __traits(valueRange, expr), and I think it introduces
 range values to the ?: expressions too.

 The __traits(valueRange, expr) is meant to be useful for debugging range
 values, that is meant to be improved in future. Currently this patch
 seems stalled because Lionello seems to not provide few small things
 Walter has asked.

 --------------------

I feel I did address his points, but more importantly there was not much 
feedback (from anyone) whether this is desirable in the first place. As 
others have noted, success rate of PRs is not that high, so it's 
defensible that the "boilerplate" tasks (such as updating the 
documentation) are left until last.

I've closed the "valueRange" PR because I now think it's not a good 
idea, since the values it returns are not stable and any code using it 
can break in the future as VRP gets smarter. The obvious cases 
("valueRange of ubyte returning 0 and 255 resp.") can already be tested 
by using implicit integer casts, as  yebblies has mentioned in that PR.

L.

"bearophile" <bearophileHUGS lycos.com> writes:

Lionello Lunesu:

 I've closed the "valueRange" PR because I now think it's not a 
 good idea, since the values it returns are not stable and any 
 code using it can break in the future as VRP gets smarter. The 
 obvious cases ("valueRange of ubyte returning 0 and 255 resp.") 
 can already be tested by using implicit integer casts, as 
  yebblies has mentioned in that PR.

OK. But the other idea (value range for if/then, and for pre/post 
conditions) is still useful.

Bye,
bearophile

Lionello Lunesu <lionello lunesu.remove.com> writes:

On 30/06/14 15:27, bearophile wrote:
 Lionello Lunesu:

 I've closed the "valueRange" PR because I now think it's not a good
 idea, since the values it returns are not stable and any code using it
 can break in the future as VRP gets smarter. The obvious cases
 ("valueRange of ubyte returning 0 and 255 resp.") can already be
 tested by using implicit integer casts, as  yebblies has mentioned in
 that PR.

 OK. But the other idea (value range for if/then, and for pre/post
 conditions) is still useful.

 Bye,
 bearophile

I'm actively developing that in my if-else-range branch. It's also part 
of the PR for issue 259, 
https://github.com/D-Programming-Language/dmd/pull/1913

It needs to get smarter still if I expect Walter to accept my fix to 
issue 259.

L.