www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Few recent dmd pull requests

reply "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
Jun 26 2014
next sibling parent 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
Jun 26 2014
prev sibling next sibling parent "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?
Jun 26 2014
prev sibling next sibling parent "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!
Jun 26 2014
prev sibling next sibling parent "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
Jun 26 2014
prev sibling next sibling parent reply "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.
Jun 26 2014
parent 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
Jun 27 2014
prev sibling next sibling parent "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
Jun 26 2014
prev sibling next sibling parent "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.
Jun 26 2014
prev sibling next sibling parent "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.
Jun 26 2014
prev sibling next sibling parent "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
Jun 26 2014
prev sibling next sibling parent "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.
Jun 26 2014
prev sibling next sibling parent "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
Jun 26 2014
prev sibling next sibling parent "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.
Jun 26 2014
prev sibling next sibling parent "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.
Jun 26 2014
prev sibling next sibling parent "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); } }
Jun 26 2014
prev sibling next sibling parent "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.
Jun 26 2014
prev sibling next sibling parent "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.
Jun 26 2014
prev sibling next sibling parent "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
Jun 26 2014
prev sibling next sibling parent "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.
Jun 26 2014
prev sibling next sibling parent 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 over 2 months ago that fixes issue #1829 (no, that's not 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.
Jun 26 2014
prev sibling next sibling parent "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 over 2 months ago that fixes issue #1829 (no, that's not 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... -Steve
Jun 26 2014
prev sibling next sibling parent "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.
Jun 26 2014
prev sibling next sibling parent "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`.
Jun 26 2014
prev sibling next sibling parent "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 little over 2 months ago that fixes issue #1829 (no, that's not 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.
Jun 26 2014
prev sibling next sibling parent "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
Jun 26 2014
prev sibling next sibling parent "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
Jun 26 2014
prev sibling next sibling parent "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
Jun 27 2014
prev sibling next sibling parent 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
Jun 27 2014
prev sibling next sibling parent "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.
Jun 27 2014
prev sibling next sibling parent "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.
Jun 27 2014
prev sibling next sibling parent reply 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.
Jun 29 2014
parent 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.
Jun 30 2014
prev sibling parent "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
Jun 30 2014