www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - property

reply "Adam D. Ruppe" <destructionator gmail.com> writes:
So the existing -property in the compiler as absolutely 
worthless. It is semantically wrong.

 property void function() func() {
         return { assert(0, "success"); };
}

void main() {
         func(); // should assert 0 success, doesn't
	auto dele = &func;
	dele(); // should assert 0 success, doesn't
}

Does the same thing with and without -property, and it is
wrong both ways.


Now, let's talk about doing it right. First, I think the entire
getter design in the compiler is counter productive. It looks
like it is part of the AssignExp... but you want getters to work
in a lot of places, not just AssignExp.



It looks to me that it actually belongs in the resolveProperties 
function in expression.c, or maybe even somewhere else since I 
tried this and it didn't quite work. I think this is operating on 
a whole line, not just the individual pieces. But regardless, it 
definitely belongs on a lower level than it is.



See, if you ask me, every single mention of a function name that 
is marked  property needs to be rewritten. This might break 
setters, but we'll cross that bridge when we come to it.


When we look back at the test code:

         func(); // should assert 0 success, doesn't
	auto dele = &func;


These two lines both currently refer to the getter function
itself. We want the getter function to be completely invisible
to all other code.


This should be rewritten kinda like if this were in the code:
   #define func (func())


This would also fix things like

func += 10;

if func returned a ref int.

===
 property ref int func() {
         static int a;
         return a;
}

void main() {
         // all of these should work; func should look just like 
an int to the outside world
         int a = func;
         int* b = &func;
         func += 10;
}
===
callexp.d(19): Error: cannot implicitly convert expression (& 
func) of type int function()  property ref to int*




Let's try running our "macro" over it

void main() {
         int a = (func());
         int* b = &(func());
         (func()) += 10;
}


What ACTUALLY happens right now is that works. Indeed, you HAVE 
to use the () right now to make it work!


What SHOULD happen:

callexp.d(18): Error: function expected before (), not func() of 
type int
callexp.d(20): Error: function expected before (), not func() of 
type int

Or something like that. Since  property ref int func() is 
supposed to be interchangable for a plain int func;, no special 
enforcement of  property syntax is required: it is illegal to 
call an int like a function, and func is an int as far as the 
outside world is concerned.


This is how the property syntax is enforced: by the compiler's 
existing type checks. No additional code should be there to check 
syntax.





So, I have two questions:

1) Do we all agree that  properties should be interchangeable for 
plain variables of the return value's type in all contexts? That 
is, if I can make this work with a pull request, is that going to 
be acceptable?

2) Does anyone who knows the compiler better want to give me some 
hints on the implementation? I'm still pretty sure the 
resolveProperties function is too far into it, but func on its 
own is just a void* to the function I believe at this point so... 
yeah that is complicating things. Perhaps *that* is what needs to 
change.


I'm also open to ideas on setters, but right now getter is what I 
want to focus on. If we have to rewrite a getter call on the left 
hand side of an assign exp into a setter call, we can figure that 
out later. Hell, it might even just work.  But one thing at a 
time.
Aug 04 2012
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
I should add: if a function is not marked  property, it should 
not change at all: it should be callable with and without parens, 
including sometimes referring to the wrong thing, exactly like it 
is now.

I come to fix code, not to break it. Rewriting references to 
 property function names should fix all property related issues 
without breaking any existing code (except that which explicitly 
specified  property but depended on the wrong semantics, code 
which is arguably already broken, just like any other bug fix can 
do.)
Aug 04 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 04/08/2012 19:13, Adam D. Ruppe a écrit :
 So the existing -property in the compiler as absolutely worthless. It is
 semantically wrong.

  property void function() func() {
 return { assert(0, "success"); };
 }

 void main() {
 func(); // should assert 0 success, doesn't
 auto dele = &func;
 dele(); // should assert 0 success, doesn't
 }

 Does the same thing with and without -property, and it is
 wrong both ways.

Note that something more is wrong. func(); // Do something auto dele = &func; dele(); // Expected to do the same thing, even if we passed throw & in the middle. The whole thing is f***ed up IMO. (and I've made some work on SDC on the subject, the & is really convoluted to implement).
 When we look back at the test code:

 func(); // should assert 0 success, doesn't
 auto dele = &func;

auto dele = func;
 These two lines both currently refer to the getter function
 itself. We want the getter function to be completely invisible
 to all other code.


 This should be rewritten kinda like if this were in the code:
 #define func (func())


 This would also fix things like

 func += 10;

 if func returned a ref int.

 What SHOULD happen:

 callexp.d(18): Error: function expected before (), not func() of type int
 callexp.d(20): Error: function expected before (), not func() of type int

+1
 Or something like that. Since  property ref int func() is supposed to be
 interchangable for a plain int func;, no special enforcement of
  property syntax is required: it is illegal to call an int like a
 function, and func is an int as far as the outside world is concerned.

+1
 1) Do we all agree that  properties should be interchangeable for plain
 variables of the return value's type in all contexts? That is, if I can
 make this work with a pull request, is that going to be acceptable?

Except for that & thing, 100% agreed.
Aug 04 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 4 August 2012 at 17:35:03 UTC, deadalnix wrote:
 Except for that & thing, 100% agreed.

I think you're right about that too...
Aug 04 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
I think I've cracked the getters...

I opened expression.c in DMD and surfed to line 2940 or so. Looks 
like this:

         {
             error("forward reference to %s", toChars());
             return new ErrorExp();
         }

         return new VarExp(loc, f, hasOverloads);


The function is



Expression *DsymbolExp::semantic(Scope *sc)


Instead of return new VarExp, I made it:


         VarExp* varexp = new VarExp(loc, f, hasOverloads);

         TypeFunction* tf = (TypeFunction *)f->type;
         if(tf->isproperty) {
             CallExp* ce = new CallExp(loc, varexp);
             ce->semantic(sc);
             return ce;
         } else {
             return varexp;
         }




And now my test functions work... the question is, did I break a 
lot of other stuff? idk, but this is a big move forward.
Aug 04 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-04 19:13, Adam D. Ruppe wrote:

 This would also fix things like

 func += 10;

 if func returned a ref int.

 ===
  property ref int func() {
          static int a;
          return a;
 }

 void main() {
          // all of these should work; func should look just like an int
 to the outside world
          int a = func;
          int* b = &func;
          func += 10;
 }
 ===
 callexp.d(19): Error: cannot implicitly convert expression (& func) of
 type int function()  property ref to int*

I don't think that's correct behavior. I think the correct behavior would be to have a property rewrite, something like this: foo += 10; Is rewritten as: auto __tmp = foo; foo = __tmp + 10;
 Or something like that. Since  property ref int func() is supposed to be
 interchangable for a plain int func;, no special enforcement of
  property syntax is required: it is illegal to call an int like a
 function, and func is an int as far as the outside world is concerned.

 This is how the property syntax is enforced: by the compiler's existing
 type checks. No additional code should be there to check syntax.

 So, I have two questions:

 1) Do we all agree that  properties should be interchangeable for plain
 variables of the return value's type in all contexts? That is, if I can
 make this work with a pull request, is that going to be acceptable?

I think that you should always be able to replace a variable with a property. The other way around I'm not so sure. The problem is with methods in classes. Since a method will be virtual by default you can't just replace a property with a variable. That could potentially break subclasses that override the property. -- /Jacob Carlborg
Aug 04 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-04 21:08, Jacob Carlborg wrote:

 I think that you should always be able to replace a variable with a
 property. The other way around I'm not so sure. The problem is with
 methods in classes. Since a method will be virtual by default you can't
 just replace a property with a variable. That could potentially break
 subclasses that override the property.

I wouldn't actually mind a way to do this, perhaps something like this: class Foo { property int bar: } Would be the same as: class Foo { private int bar_: property int bar () { return bar_; } property int bar (int value) { return bar_ = value; } } -- /Jacob Carlborg
Aug 04 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-04 21:28, Jonathan M Davis wrote:

 That would be kind of cool, though I would have suggested that putting
  property on a variable would make it so that you couldn't do anything with it
 that you couldn't do with a property (e.g. taking the address of a variable
 will break when it's switched to a property, and  property on the variable
 could prevent that). But maybe your proposal is better - though I'm not sure
 how much I'd end up using it, because if you wanted to actually use the member
 variable, you'd get into naming issues. You proposed bar_ here, but I'd have
 gone with _bar, whereas some would have suggested m_bar, and regardless,
 there's no way to indicate the name with this syntax, so you'd have to either
 just know how the compiler names such variables or statically disallow using
 the property through anything other than the proprty functions. And if all the
 property does is get and set with _nothing_ else, then how is that any better
 than a public member variable, assuming that switching between a variable and
 a property is seemless like it's supposed to be? So, I think that I'd still
 prefer the approach of making it so that marking variables  property makes it
 so that you can only use them in ways that you can use a property function,
 since it gives you the same result without needing to actually create any
 functions or come up with naming schemes for implicit member variables or
 whatnot.

I see two reasons: 1. The generated methods will be virtual 2. I'm thinking that it would be possible to override either the getter or setter. Meaning you would get one for free class Foo { property int bar: property int bar (int value) { validate(value); return bar_ = value; } } In the above code, only a getter will be generated. About the name of generate instance variable, we could add syntax making it possible to change the name: class Foo { property(name=m_bar) int bar: } -- /Jacob Carlborg
Aug 05 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-04 21:28, Jonathan M Davis wrote:

 That would be kind of cool, though I would have suggested that putting
  property on a variable would make it so that you couldn't do anything with it
 that you couldn't do with a property (e.g. taking the address of a variable
 will break when it's switched to a property, and  property on the variable
 could prevent that). But maybe your proposal is better - though I'm not sure
 how much I'd end up using it, because if you wanted to actually use the member
 variable, you'd get into naming issues. You proposed bar_ here, but I'd have
 gone with _bar, whereas some would have suggested m_bar, and regardless,
 there's no way to indicate the name with this syntax, so you'd have to either
 just know how the compiler names such variables or statically disallow using
 the property through anything other than the proprty functions. And if all the
 property does is get and set with _nothing_ else, then how is that any better
 than a public member variable, assuming that switching between a variable and
 a property is seemless like it's supposed to be? So, I think that I'd still
 prefer the approach of making it so that marking variables  property makes it
 so that you can only use them in ways that you can use a property function,
 since it gives you the same result without needing to actually create any
 functions or come up with naming schemes for implicit member variables or
 whatnot.

A few more reasons: 3. Binary compatibility 4. Read only fields. I quite often want to have read only fields and basically the only way to that is by using a getter property method. In D1 I could sometimes avoid this by declaring the instance variable as const, but that doesn't work in D2 -- /Jacob Carlborg
Aug 05 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-04 21:25, Adam D. Ruppe wrote:

 Yes, I agree in general, but if a getter returns a ref, you should
 be able to write to it... I think anyway, but it is an lvalue anyway.

Or we could disallow getters returning by reference.
 What I just added to my hacked compiler is this:

 =====
   else if(e1->op == TOKcall) {
              // for property work, if there is a setter, we should
 revert to the older style
              // handling. If not, we can keep it as a CallExp
              CallExp* ce = (CallExp*) e1;
              Expression* temp_e1 = ce->e1;
              if((temp_e1->op == TOKvar &&
 temp_e1->type->toBasetype()->ty == Tfunction)) {
                  // this is potentially a setter.... but not necessarily
                  fd = ((VarExp *)temp_e1)->var->isFuncDeclaration();
                  ethis = NULL;
                  assert(fd);
                  FuncDeclaration *f = fd;
                  Expressions a;
                  a.push(e2);

                  fd = f->overloadResolve(loc, ethis, &a, 1);
                  if (fd && fd->type) {
                      e1 = temp_e1;
                      goto Lsetter;
                  }
              }
 =====


 To line 10320 - right above where the old style setter code is. It isn't
 perfect yet because it doesn't ensure we are dealing with a  property,
 but it is closer.



 The idea is: if we have a setter function, we should try to use it, just
 like dmd does today. If not, we'll leave the call there and see what
 happens. (If it returns ref, it will work, otherwise, it errors saying
 the property is not an lvalue.)


 So far this is passing my simple test for assignment, but not yet the op
 assigns.

 int a;
  property int funcprop() {
          return a;
 }

 // setter
  property int funcprop(int s) {
          return a = s + 10;
 }

 funcprop = 10; // works, funcprop == 20 now

Doesn't this already work?
 True. I think all the other uses should just work though.

Yes. Have a look at this for a workaround: http://forum.dlang.org/thread/gknbobkfhmfszshqenng forum.dlang.org#post-jvjs5j:248ov:241:40digitalmars.com -- /Jacob Carlborg
Aug 05 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-08-05 15:51, Adam D. Ruppe wrote:

 And then I need to check the operator overloading.

I see.
 I saw it, but one step at a time for now...

Hehe, yes, of course. No pressure :) -- /Jacob Carlborg
Aug 05 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-04 23:35, Adam D. Ruppe wrote:
 OK, I just compiled one of my work apps with the hacked up dmd.

 It caught me using properties as functions in a few places, which I had
 to fix by removing the parenthesis from some places, and the  property
 from a few other places (the functions weren't really properties, I just
 marked them as such for the syntax...)


 But hey if it compiles this thing with only a few, very minor changes, I
 think we're in business. We should be able to close those gazillion
 ancient property bugs once and for all, with minimal code breakage.

 I'll push it up to github later tonight for additional review.

Awesome :) -- /Jacob Carlborg
Aug 05 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-04 22:53, Adam D. Ruppe wrote:

 I did this and now I think this thing is almost done

 ===
 int a;
  property int funcprop() {
          writeln("calling the getter and getting ", a);
      return a;
 }
  property int funcprop(int s) {
      writeln("calling the setter with ", s);
      return a = s;
 }
 void main() {
      funcprop = 40;
      funcprop += 10;
 }
 ===

 run:

 calling the setter with 40
 calling the getter and getting 40
 calling the setter with 50

 Looks right to me. Now I just have to check for the  property tag on
 some of these rewrites and then clean it up and test for a pull request.

BTW, how will this interact with overloaded operators and similar more advanced features? Say that I have a getter that returns a struct/class which overloads the += operator. -- /Jacob Carlborg
Aug 05 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 4 August 2012 at 19:08:58 UTC, Jacob Carlborg wrote:
 I don't think that's correct behavior. I think the correct 
 behavior would be to have a property rewrite, something like 
 this:

Yes, I agree in general, but if a getter returns a ref, you should be able to write to it... I think anyway, but it is an lvalue anyway. What I just added to my hacked compiler is this: ===== else if(e1->op == TOKcall) { // for property work, if there is a setter, we should revert to the older style // handling. If not, we can keep it as a CallExp CallExp* ce = (CallExp*) e1; Expression* temp_e1 = ce->e1; if((temp_e1->op == TOKvar && temp_e1->type->toBasetype()->ty == Tfunction)) { // this is potentially a setter.... but not necessarily fd = ((VarExp *)temp_e1)->var->isFuncDeclaration(); ethis = NULL; assert(fd); FuncDeclaration *f = fd; Expressions a; a.push(e2); fd = f->overloadResolve(loc, ethis, &a, 1); if (fd && fd->type) { e1 = temp_e1; goto Lsetter; } } ===== To line 10320 - right above where the old style setter code is. It isn't perfect yet because it doesn't ensure we are dealing with a property, but it is closer. The idea is: if we have a setter function, we should try to use it, just like dmd does today. If not, we'll leave the call there and see what happens. (If it returns ref, it will work, otherwise, it errors saying the property is not an lvalue.) So far this is passing my simple test for assignment, but not yet the op assigns. int a; property int funcprop() { return a; } // setter property int funcprop(int s) { return a = s + 10; } funcprop = 10; // works, funcprop == 20 now funcprop += 10; // currently does NOT work
 Is rewritten as:

 auto __tmp = foo;
 foo = __tmp + 10;

I think this is exactly what we have to do to work in all cases. I'm gonna take a look at it next... then it is time to test this patch and with a little luck, we can finally put the property debate to rest.
 I think that you should always be able to replace a variable 
 with a property. The other way around I'm not so sure. The 
 problem is with methods in classes. Since a method will be 
 virtual by default you can't just replace a property with a 
 variable. That could potentially break subclasses that override 
 the property.

True. I think all the other uses should just work though.
Aug 04 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 04, 2012 21:11:47 Jacob Carlborg wrote:
 On 2012-08-04 21:08, Jacob Carlborg wrote:
 I think that you should always be able to replace a variable with a
 property. The other way around I'm not so sure. The problem is with
 methods in classes. Since a method will be virtual by default you can't
 just replace a property with a variable. That could potentially break
 subclasses that override the property.

I wouldn't actually mind a way to do this, perhaps something like this: class Foo { property int bar: } Would be the same as: class Foo { private int bar_: property int bar () { return bar_; } property int bar (int value) { return bar_ = value; } }1

That would be kind of cool, though I would have suggested that putting property on a variable would make it so that you couldn't do anything with it that you couldn't do with a property (e.g. taking the address of a variable will break when it's switched to a property, and property on the variable could prevent that). But maybe your proposal is better - though I'm not sure how much I'd end up using it, because if you wanted to actually use the member variable, you'd get into naming issues. You proposed bar_ here, but I'd have gone with _bar, whereas some would have suggested m_bar, and regardless, there's no way to indicate the name with this syntax, so you'd have to either just know how the compiler names such variables or statically disallow using the property through anything other than the proprty functions. And if all the property does is get and set with _nothing_ else, then how is that any better than a public member variable, assuming that switching between a variable and a property is seemless like it's supposed to be? So, I think that I'd still prefer the approach of making it so that marking variables property makes it so that you can only use them in ways that you can use a property function, since it gives you the same result without needing to actually create any functions or come up with naming schemes for implicit member variables or whatnot. - Jonathan M Davis
Aug 04 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 4 August 2012 at 19:08:58 UTC, Jacob Carlborg wrote:
 foo += 10;

 Is rewritten as:

 auto __tmp = foo;
 foo = __tmp + 10;

I did this and now I think this thing is almost done === int a; property int funcprop() { writeln("calling the getter and getting ", a); return a; } property int funcprop(int s) { writeln("calling the setter with ", s); return a = s; } void main() { funcprop = 40; funcprop += 10; } === run: calling the setter with 40 calling the getter and getting 40 calling the setter with 50 Looks right to me. Now I just have to check for the property tag on some of these rewrites and then clean it up and test for a pull request.
Aug 04 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
OK, I just compiled one of my work apps with the hacked up dmd.

It caught me using properties as functions in a few places, which 
I had to fix by removing the parenthesis from some places, and 
the  property from a few other places (the functions weren't 
really properties, I just marked them as such for the syntax...)


But hey if it compiles this thing with only a few, very minor 
changes, I think we're in business. We should be able to close 
those gazillion ancient property bugs once and for all, with 
minimal code breakage.

I'll push it up to github later tonight for additional review.
Aug 04 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 04, 2012 23:35:47 Adam D. Ruppe wrote:
 OK, I just compiled one of my work apps with the hacked up dmd.
 
 It caught me using properties as functions in a few places, which
 I had to fix by removing the parenthesis from some places, and
 the  property from a few other places (the functions weren't
 really properties, I just marked them as such for the syntax...)
 
 
 But hey if it compiles this thing with only a few, very minor
 changes, I think we're in business. We should be able to close
 those gazillion ancient property bugs once and for all, with
 minimal code breakage.
 
 I'll push it up to github later tonight for additional review.

If you can get properties working properly that quickly, that's fantastic. - Jonathan M Davis
Aug 04 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 4 August 2012 at 21:47:44 UTC, Jonathan M Davis 
wrote:
 If you can get properties working properly that quickly, that's 
 fantastic.

I did just realize I missed something.... but I'm convinced the problem before is we were going at it at the wrong time, doing the property rewrites too late, meaning it had to be duplicated a lot and was hard to check fully. My approach here is to rewrite the properties almost immediately into function calls instead of leaving them as just function references until the last minute. (And then in a couple places, they need to be turned back into references so you can look up the setter, but I say better to only need two special cases than twenty.)
Aug 04 2012
prev sibling next sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
There was a very long discussion on this before that lead me to write this:

http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property

I should draw attention to the tables near the bottom.  It is really too 
bad that variables in D allow the taking of addresses by default.  If 
things were non-addressable by default, then they could always be 
promoted to properly-implemented properties.  Addressabilitiy could be 
added explicitly by authors that are confident that they will never need 
to turn their public fields into properties.  Too late for all of that 
now.

I tried to get DMD to do property rewriting in a vaguely general sense. 
  I think it's still very worthwhile to attempt it.

It didn't work for me because this was in the days of SVN and I tend to 
get my free time in 1-3 hour chunks.  By the time I had more free time 
I'd spend it all merging/updating my code to the latest revision.  I 
also spent a lot of my time learning how DMD's semantic analysis works. 
  It's pretty tangled (sorry, Walter).  So yeah, I didn't get to spend 
much time actually working on the property rewrite due to confusion and 
backtracking.  I realized that while I really wanted the feature, I 
wasn't having fun, nor did I have any free time to program at all. 
(Implementing the recursive logic for such a rewrite is really easy! 
Dealing with DMDs architectural corner cases... (was) not so easy.)

It'd probably be good to be minimal about it.  We might not be able to 
do property rewriting in a %100 awesome way without breaking backwards 
compatibility.  It'll still be worth it to get the property rewriting 
that doesn't break backwards compatibility.  Example:

struct Bar
{
	private Foo m_a;
	
	 property Foo a()
	{
		return m_a;
	}
}

struct Foo
{
	private int qux;

	Foo opBinary(string op : "+")(Foo other)
	{
		Foo result;
		result.qux = this.qux + other.qux
		return result;
	}
}

void main()
{
	Bar a;
	Foo b;

	// Error: attempt to write to a non-writable property a.a
	b = a.a + b;
}

To make the property rewrite bulletproof, we have to assume that (a.f + 
b) will modify a.a because a.a.opBinary!("+") is non-const.  We should 
then compile-time-error because the property a.a does not have a setter.
However, in current code, this would not give a compile-time error. 
Instead it would just work, because the caller and callee implicitly 
assume that the opBinary call is const, even if it's not marked as such. 
  There is probably a significant amount of code that would no longer 
compile because of this.  The answer would be to mark all such functions 
as const, but I'm not sure that Walter & Co would be fine with that.

It's OK though.  If Walter & Co don't want to break various calls to 
non-const functions at the end of expressions containing properties, 
then we can let that slide and only focus on the more likely cases like 
using += on a property field that returns a value type like an int 
(array.length += 1 is the classic case, with its own special-cased 
solution and everything).  It'd be extremely useful and possibly remove 
a lot of potential sources of bugs/headaches.

Anyhow, that's a lot of my background info on this subject.  I do hope 
someone else tackles this.  They will probably be more successful than 
I.  If not, I might still try it someday if the pull request might get 
accepted.
Aug 04 2012
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 08/04/2012 06:50 PM, Adam D. Ruppe wrote:
 On Saturday, 4 August 2012 at 22:19:17 UTC, Chad J wrote:
 There was a very long discussion on this before that lead me to write
 this:

I'll have to read it... my thing right now works, as far as I can tell, perfectly on free function properties. But member properties are different and I haven't gotten them to work without massive breakage yet. (I forgot all about them until just an hour ago.) For some reason, rewriting the members breaks random things like opCall too. The good is the free function change doesn't actually break anything... the bad is member properties are the more interesting ones and if they don't work, this isn't cool.... But it doesn't look like I'll be done with this today after all :( I still have a lot of stuff I was supposed to be doing today!

Best of luck, and thank you for thinking about this and getting the ball rolling!
Aug 04 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 4 August 2012 at 22:19:17 UTC, Chad J wrote:
 There was a very long discussion on this before that lead me to 
 write this:

I'll have to read it... my thing right now works, as far as I can tell, perfectly on free function properties. But member properties are different and I haven't gotten them to work without massive breakage yet. (I forgot all about them until just an hour ago.) For some reason, rewriting the members breaks random things like opCall too. The good is the free function change doesn't actually break anything... the bad is member properties are the more interesting ones and if they don't work, this isn't cool.... But it doesn't look like I'll be done with this today after all :( I still have a lot of stuff I was supposed to be doing today!
Aug 04 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 I should add: if a function is not marked  property, it should 
 not change at all: it should be callable with and without 
 parens,

I think I'd like functions not marked with property to require the (). Bye, bearophile
Aug 04 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 5 August 2012 at 02:17:18 UTC, bearophile wrote:
 I think I'd like functions not marked with  property to require 
 the ().

You have the -property switch for breaking piles of perfectly good code while enabling no new functionality. What I'm doing is completely independent of -property: I'm making properties actually work. And I'm almost there... I just got the struct members working but introduced a regression where dmd assert fails.
Aug 04 2012
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 05-Aug-12 18:32, Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
 I'd be very surprised if all that many people compile with -property.

Indeed. Sometimes I try it just to see what happens, and always the same results: it doesn't solve problems and complains about code.

+1 [snip]
 And now the UFCS map, filter, etc. chains and whatnot are just icing on
 the cake. Bearophile, I've seen you complain about the mess of
 parenthesis in std.algorithm before. With ufcs and template arguments,
 you can be rid of many of them. It is actually pretty beautiful, even to
 me.

 Do you really want to break that now?


 My position right now is  property has a strict syntax out of necessity.
 Stuff without  property should work the way it does now - thus
 minimizing broken code to that which already opted-in to  property
 (which generally does it right anyway), while keeping the status quo on
 the rest. It can turn out ugly, I'll agree, but it can be beautiful too
 and just plain isn't worth the code breakage either way.

Well in the end I think strict property enforcement was meant to solve some corner cases (e.g. returning delegates from, and taking address of no-arg functions). But then it promptly killed at least one cool idiom (chaining & assignment in one name). Then once UFCS was finally working property spoiled it (e.g. your algorithm examples). So I'm with you - let non- property work as before, and property ones to be god damn properly enforced. -- Dmitry Olshansky
Aug 05 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/07/2012 07:59 AM, José Armando García Sancio wrote:
 On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam gmail.com>  wrote:
 On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
 I'd be very surprised if all that many people compile with -property.

Indeed. Sometimes I try it just to see what happens, and always the same results: it doesn't solve problems and complains about code. Some examples of things that break: import std.algorithm; foreach(i; [1,2,3].map!"a+1") { } prophate.d(5): Error: not a property [1,2,3].map!("a+1") Of course, this is relatively new, using ufcs in 2.059, so the breakage probably isn't too bad, but I'm not the only one who writes it this way - I've seen a number of reddit and newsgroup comments do this too, especially when chaining it. [snip]

I completely agree, particularl with the UFCS part. UFCS is designed to get rid of the horrible mess of (), and now we want to arbitrarily force a () anyways? Seems like it defeats the purpose. To me, when comparing range.filter!"a> 2".map!"a*a".countUntil(3) to range.filter!"a> 2"().map!"a*a"().countUntil(3) Those extra paranthesis just don't do anything, they don't give extra meaning, they don't accomplish anything useful but distract from the actual expression.

Just a small comment. I have been following this thread a little and was somewhat surprise that the argument against enforcing parenthesis on non-properties is that a call like [1,2,3].map!"a+1" would look ugly as [1,2,3].map!"a+1"(). To me that is a issue of the std.algorithm module and not so much of the language. Personally I am not a huge fan of using strings as a way to pass a function into a high-order function. I suspect that this string stuff became popular because D didn't have lambda declarations and type inference when the module was designed and implemented.

String lambdas would quite certainly have been left out. Anyway, string lambdas are unrelated to the discussion of std.algorithm idioms in this context. [1,2,3].map!(a=>a+1) [1,2,3].map!(a=>a+1)()
Aug 07 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-07 20:37, José Armando García Sancio wrote:

 Yep. The "problem" is not string lambda but that the mapping function
 is passed a template argument (which you need for string lambda to
 work). I guess that this is nice because you can alias the template or
 pass multiple lambdas (a little obscure but okay). If the lambda
 function was passed as a runtime parameter and not a template
 parameter can just do:

 [1, 2, 3].map(a=>a+1)

I'm not entirely sure but I think using an alias-parameter the delegate will be inlined. Delegates are in general not inlined. -- /Jacob Carlborg
Aug 07 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/07/2012 08:37 PM, José Armando García Sancio wrote:
 On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr<timon.gehr gmx.ch>  wrote:
 On 08/07/2012 07:59 AM, José Armando García Sancio wrote:
 On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam gmail.com>   wrote:
 On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
 I'd be very surprised if all that many people compile with -property.

Indeed. Sometimes I try it just to see what happens, and always the same results: it doesn't solve problems and complains about code. Some examples of things that break: import std.algorithm; foreach(i; [1,2,3].map!"a+1") { } prophate.d(5): Error: not a property [1,2,3].map!("a+1") Of course, this is relatively new, using ufcs in 2.059, so the breakage probably isn't too bad, but I'm not the only one who writes it this way - I've seen a number of reddit and newsgroup comments do this too, especially when chaining it. [snip]

I completely agree, particularl with the UFCS part. UFCS is designed to get rid of the horrible mess of (), and now we want to arbitrarily force a () anyways? Seems like it defeats the purpose. To me, when comparing range.filter!"a> 2".map!"a*a".countUntil(3) to range.filter!"a> 2"().map!"a*a"().countUntil(3) Those extra paranthesis just don't do anything, they don't give extra meaning, they don't accomplish anything useful but distract from the actual expression.

Just a small comment. I have been following this thread a little and was somewhat surprise that the argument against enforcing parenthesis on non-properties is that a call like [1,2,3].map!"a+1" would look ugly as [1,2,3].map!"a+1"(). To me that is a issue of the std.algorithm module and not so much of the language. Personally I am not a huge fan of using strings as a way to pass a function into a high-order function. I suspect that this string stuff became popular because D didn't have lambda declarations and type inference when the module was designed and implemented.

String lambdas would quite certainly have been left out. Anyway, string lambdas are unrelated to the discussion of std.algorithm idioms in this context. [1,2,3].map!(a=>a+1) [1,2,3].map!(a=>a+1)()

Yep. The "problem" is not string lambda but that the mapping function is passed a template argument (which you need for string lambda to work).

It is also a matter of execution speed and GC pressure. None of the D compilers is able to inline delegate parameters at least as well as alias template parameters afaik. Furthermore, only the current form can _guarantee_ that no hidden GC allocations take place due to parameter passing to map.
 I guess that this is nice because you can alias the template or
 pass multiple lambdas (a little obscure but okay). If the lambda
 function was passed as a runtime parameter and not a template
 parameter can just do:

 [1, 2, 3].map(a=>a+1)

Well, no you cannot, because the current language would not be able to deduce a type for 'a'.
 If this was the case we wouldn't be talking about this non-property vs
 property with regard to map.

We would be talking about improving IFTI to support cross-parameter type deduction. (and maybe we would constantly be complaining about poor GC performance.) Some programmers who use it now would presumably avoid std.algorithm because of the poor predictability of performance.
Aug 07 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/07/2012 10:52 PM, José Armando García Sancio wrote:
 On Tue, Aug 7, 2012 at 12:27 PM, Timon Gehr<timon.gehr gmx.ch>  wrote:
 On 08/07/2012 08:37 PM, José Armando García Sancio wrote:
 On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr<timon.gehr gmx.ch>   wrote:
 On 08/07/2012 07:59 AM, José Armando García Sancio wrote:

 On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam gmail.com>    wrote:
 On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
 I'd be very surprised if all that many people compile with -property.

Indeed. Sometimes I try it just to see what happens, and always the same results: it doesn't solve problems and complains about code. Some examples of things that break: import std.algorithm; foreach(i; [1,2,3].map!"a+1") { } prophate.d(5): Error: not a property [1,2,3].map!("a+1") Of course, this is relatively new, using ufcs in 2.059, so the breakage probably isn't too bad, but I'm not the only one who writes it this way - I've seen a number of reddit and newsgroup comments do this too, especially when chaining it. [snip]

I completely agree, particularl with the UFCS part. UFCS is designed to get rid of the horrible mess of (), and now we want to arbitrarily force a () anyways? Seems like it defeats the purpose. To me, when comparing range.filter!"a> 2".map!"a*a".countUntil(3) to range.filter!"a> 2"().map!"a*a"().countUntil(3) Those extra paranthesis just don't do anything, they don't give extra meaning, they don't accomplish anything useful but distract from the actual expression.

Just a small comment. I have been following this thread a little and was somewhat surprise that the argument against enforcing parenthesis on non-properties is that a call like [1,2,3].map!"a+1" would look ugly as [1,2,3].map!"a+1"(). To me that is a issue of the std.algorithm module and not so much of the language. Personally I am not a huge fan of using strings as a way to pass a function into a high-order function. I suspect that this string stuff became popular because D didn't have lambda declarations and type inference when the module was designed and implemented.

String lambdas would quite certainly have been left out. Anyway, string lambdas are unrelated to the discussion of std.algorithm idioms in this context. [1,2,3].map!(a=>a+1) [1,2,3].map!(a=>a+1)()

Yep. The "problem" is not string lambda but that the mapping function is passed a template argument (which you need for string lambda to work).

It is also a matter of execution speed and GC pressure. None of the D compilers is able to inline delegate parameters at least as well as alias template parameters afaik. Furthermore, only the current form can _guarantee_ that no hidden GC allocations take place due to parameter passing to map.

Interesting. I can't speak for the GC and allocation you mention since I never tried to implement this myself but I should point out that C++ STL's algorithm "module" (transform, for_each, etc) works this way. Having said that, if D can't infer the type of lambda parameters (which I thought the current version of D could) and create a function/delegate based on the body then this is a no go. Thanks for you insight. -Jose

The reason it works in C++ for transform, for_each etc. is because those functions are eager. Allocation-free transform with runtime delegate in D: import std.algorithm, std.range; void transform(IR,OR,I,O)(IR input, OR output, scope O delegate(I) dg) if(is(typeof(input.map!dg.copy(output)))) { input.map!dg.copy(output); } void main(){ int[3] result; int b = 1; [1,2,3].transform(result[], (int a)=>a+b); assert(result[] == [2,3,4]); } Note that parameter type deduction is lost for the delegate. I'd like type deduction to work if the signature of 'transform' is changed to: void transform(IR,OR,I=ElementType!IR,O)(IR input, OR output, scope O delegate(I) dg); [1,2,3].transform(result[], a=>a+b); Lazy map with runtime delegate would have to remember the delegate, therefore it could not be a scope delegate.
Aug 07 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, August 05, 2012 04:17:13 bearophile wrote:
 Adam D. Ruppe:
 I should add: if a function is not marked  property, it should
 not change at all: it should be callable with and without
 parens,

I think I'd like functions not marked with property to require the ().

I wholeheartedly agree, but it's a divisive subject. Some of us feel very strongly that functions not marked with property should require parens, and others feel very strongly that they should be optional. - Jonathan M Davis
Aug 04 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, August 05, 2012 04:25:26 Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 02:17:18 UTC, bearophile wrote:
 I think I'd like functions not marked with  property to require
 the ().

You have the -property switch for breaking piles of perfectly good code while enabling no new functionality. What I'm doing is completely independent of -property: I'm making properties actually work. And I'm almost there... I just got the struct members working but introduced a regression where dmd assert fails.

And I think that the only thing that the -property switch currently gets _right_ is complaining about non-property functions getting called with parens. It's very buggy. Regardless, there are indeed two general issues here: 1. Make property work in general. 2. Make -property work correctly. - Jonathan M Davis
Aug 04 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 You have the -property switch for breaking piles of perfectly 
 good code while enabling no new functionality.

The -property switch is present since lot of time, and I think most people that write D2 code compile their libraries with -property. So I don't think it breaks lot of D2 code today.
 What I'm doing is completely independent of -property: I'm 
 making  properties actually work.

I understand. Don't rush things, even if your design takes few days we are dealing with those problems since years, so few more days are not a problem. Bye, bearophile
Aug 04 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, August 05, 2012 05:59:34 bearophile wrote:
 Adam D. Ruppe:
 You have the -property switch for breaking piles of perfectly
 good code while enabling no new functionality.

The -property switch is present since lot of time, and I think most people that write D2 code compile their libraries with -property. So I don't think it breaks lot of D2 code today.

I'd be very surprised if all that many people compile with -property. I'm pretty sure that there are a lot of people (the majority?) who don't even compile with -w or -wi. Obviously, some people do, but from what I've seen, I'd guess that most people compile with the bare minimum flags required, and - property is _very_ buggy anyway. - Jonathan M Davis
Aug 04 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 5 August 2012 at 12:18:52 UTC, Jacob Carlborg wrote:
 BTW, how will this interact with overloaded operators and 
 similar more advanced features? Say that I have a getter that 
 returns a struct/class which overloads the += operator.

I'm not sure yet... stuff like this is one reason why it didn't work out right last night. (I have it working in about 90% of cases, but it is interaction with those last advanced features that always keep the D bugzilla active.) With the rewrite right now, it does getter -> opOpAssign -> setter, which isn't quite right...
Aug 05 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 5 August 2012 at 12:14:41 UTC, Jacob Carlborg wrote:
 Doesn't this already work?

Yes, but it is in my test file to make sure it still works, without any additional pointless function calls. Right now the basics all work, but member template function that happen to be getters can break - this is the assertion failure I saw last night. I think my fix to implicit this calls broke it, ugh. And then I need to check the operator overloading.
 Yes. Have a look at this for a workaround:

I saw it, but one step at a time for now...
Aug 05 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
 I'd be very surprised if all that many people compile with 
 -property.

Indeed. Sometimes I try it just to see what happens, and always the same results: it doesn't solve problems and complains about code. Some examples of things that break: import std.algorithm; foreach(i; [1,2,3].map!"a+1") { } prophate.d(5): Error: not a property [1,2,3].map!("a+1") Of course, this is relatively new, using ufcs in 2.059, so the breakage probably isn't too bad, but I'm not the only one who writes it this way - I've seen a number of reddit and newsgroup comments do this too, especially when chaining it. Another thing I do is I have a template function called getDocument in a lot of my code. It takes the document name as a template param, because in a lot of cases, I want to build the doc at compile time. auto document = getDocument!"about-me"; Is that a function or a property? I think it is a function, it does a lot work. But, the arguments are there already... do we really need to say getDocument!"about-me"() just to appease a compiler switch? (This function also can take some runtime params, but it has defaults so param less calling works as well.) What about std.conv? This works fine in all old code - its functions either naturally require parens (such as to!(int)("10"), gotta have at least the outer set, or octal!"555" - it is an enum, so gotta not use them).... but with UFCS, that's actually out the window now: int i = "10".to!int; prophate.d(4): Error: not a property "10".to!(int) Now, I've never actually written this. With map!(), I do that in the real world, but not with this. Still, I could imagine someone who might. If we had the strictness before 2.059, I could live with it. Just add the () (though, then queue the people complaining about syntatic noise!). But, now we're several months past that. I say that ship has sailed. The big breakage for me is something I have been doing for years though, and that's using my dom.d with chaining: import arsd.dom; // in one place I might use: auto ele = Element.make("span", "Hello").className("hello").setAttribute("foo", "bar"); // but in another I say: ele.className = "something"; Now, many of my newer functions obviate this kind of thing; Element.make now offers overloads for inner text, inner html, and common attributes. There's now an addClass() so it isn't all dependent on className. But, there's still hundreds of lines of me using the older functions like this, and every so often, it still comes up. What happens with -property? prophate.d(7): Error: not a property ele.className arsd/domconvenience.d(49): Error: not a property className arsd/domconvenience.d(81): Error: not a property n.strip arsd/domconvenience.d(81): Error: not a property className arsd/domconvenience.d(88): Error: not a property className arsd/domconvenience.d(218): Error: not a property e.innerHTML arsd/dom.d(201): Error: not a property e.innerText arsd/dom.d(212): Error: not a property e.innerText arsd/dom.d(217): Error: not a property e.innerText arsd/dom.d(232): Error: not a property e.innerText arsd/dom.d(234): Error: not a property e.className arsd/dom.d(242): Error: not a property m.innerHTML arsd/dom.d(506): Error: not a property name.toLower arsd/dom.d(508): Error: not a property value.strip arsd/dom.d(1162): Error: not a property child.innerText arsd/dom.d(1634): Error: not a property innerText arsd/dom.d(1831): Error: not a property e.innerText arsd/dom.d(1859): Error: not a property child.innerText arsd/dom.d(1913): Error: not a property e.innerText arsd/dom.d(2135): Error: not a property this.captionElement().innerText arsd/dom.d(2140): Error: not a property this.captionElement().innerText wooo, but only the first line is this specific example. You can also see in here strip() and toLower() on which is just me being lax: auto v = value.strip.toLower(); for example. Adding the inner parens would be annoying but it wouldn't require changing the form of the code like changing the dual use ones. ....huh, my example here actually does work if I set property, but still use it as a function. Buggy switch. But I know I've tried this before and had one set of usages break with property and another break without it. Maybe it was innerHTML, which can also be overloaded to take an Appender argument. Yeah, then I get this: arsd/dom.d(982): Error: cannot overload both property and non-property functions There's just no winning without redoing a LOT of code, changing names, changing some expressions into statements since the chaining is out, duplicating functionality across two functions when one could do... It was at that point that I decided it'd be better to put my effort into killing -property than trying to "fix" my code to appease its idiotic demands. And now the UFCS map, filter, etc. chains and whatnot are just icing on the cake. Bearophile, I've seen you complain about the mess of parenthesis in std.algorithm before. With ufcs and template arguments, you can be rid of many of them. It is actually pretty beautiful, even to me. Do you really want to break that now? My position right now is property has a strict syntax out of necessity. Stuff without property should work the way it does now - thus minimizing broken code to that which already opted-in to property (which generally does it right anyway), while keeping the status quo on the rest. It can turn out ugly, I'll agree, but it can be beautiful too and just plain isn't worth the code breakage either way.
Aug 05 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 05 Aug 2012 16:32:49 +0200, Adam D. Ruppe  
<destructionator gmail.com> wrote:

 import std.algorithm;
 foreach(i; [1,2,3].map!"a+1") {

 }
 prophate.d(5): Error: not a property [1,2,3].map!("a+1")


 Of course, this is relatively new, using ufcs in 2.059, so the breakage  
 probably isn't too bad, but I'm not the only one who writes it this way  
 - I've seen a number of reddit and newsgroup comments do this too,  
 especially when chaining it.

Yeah. I seem to do that every single time I want to give an example. -- Simen
Aug 05 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 octal!"555" - it is an enum, so gotta not use them).... but 
 with UFCS, that's actually out the window now:

What about turning octal into a propety to fix this problem?
 There's just no winning without redoing a LOT of code, changing 
 names, changing some expressions into statements since the 
 chaining is out, duplicating functionality across two functions 
 when one could do...

All my large amount of D2 code gives no warning with -property. Maybe you should fix your code. Bye, bearophile
Aug 05 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 5 August 2012 at 15:45:37 UTC, bearophile wrote:
 What about turning octal into a propety to fix this problem?

octal actually works because it isn't a function. But in general, changing non-properties to properties just for syntax is backward anyway. Whether something is a property or not isn't a question of parenthesis. I think it was a mistake to conflate "property" with "parenthesis-less syntax" in the first place, since they aren't really the same thing. A getX/setX pair in C++ is conceptually a property, but uses a different syntax. A method call in Ruby is still a method call, despite being able to write it without parens. Something should be marked property because it fits the conceptual definition, not because you want to leave parens out. That's also why I don't like -property's implementation: it focuses purely on the syntax, without worrying about the concept. If you get the concept right, the syntax will fit on its own - for example, a property returning an int shouldn't be callable with () because calling an int like a function is nonsense regardless.
 All my large amount of D2 code gives no warning with -property. 
 Maybe you should fix your code.

Maybe you should pay my mortgage.
Aug 05 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 Maybe you should pay my mortgage.

I understand. The kind of programs I write enjoy run-time errors raised on overflow on integral values operations. Recently I opened a silly thread about this in D learn. Adding those to D will help me pay my bills and better keep my mind. Bye, bearophile
Aug 05 2012
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis 
 wrote:
 I'd be very surprised if all that many people compile with 
 -property.

Indeed. Sometimes I try it just to see what happens, and always the same results: it doesn't solve problems and complains about code. Some examples of things that break: import std.algorithm; foreach(i; [1,2,3].map!"a+1") { } prophate.d(5): Error: not a property [1,2,3].map!("a+1") Of course, this is relatively new, using ufcs in 2.059, so the breakage probably isn't too bad, but I'm not the only one who writes it this way - I've seen a number of reddit and newsgroup comments do this too, especially when chaining it. [snip]

I completely agree, particularl with the UFCS part. UFCS is designed to get rid of the horrible mess of (), and now we want to arbitrarily force a () anyways? Seems like it defeats the purpose. To me, when comparing range.filter!"a > 2".map!"a*a".countUntil(3) to range.filter!"a > 2"().map!"a*a"().countUntil(3) Those extra paranthesis just don't do anything, they don't give extra meaning, they don't accomplish anything useful but distract from the actual expression. Most importantly though, with the focus on avoiding breaking code, why are we putting in -property which has the *sole* purpose of breaking existing code. And a whole lot of it at that. Never mind that a huge number of people strongly dislike the idea of enforcing paranthesis in the first place. It's not even about whether I agree with enforcing it, it's that I strongly disagree with breaking code for no benefit besides what some people will arbitrarily think is cleaner code, and others will not.
Aug 05 2012
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
On Saturday, 4 August 2012 at 20:53:53 UTC, Adam D. Ruppe wrote:
 On Saturday, 4 August 2012 at 19:08:58 UTC, Jacob Carlborg 
 wrote:
 foo += 10;

 Is rewritten as:

 auto __tmp = foo;
 foo = __tmp + 10;

I did this and now I think this thing is almost done === int a; property int funcprop() { writeln("calling the getter and getting ", a); return a; } property int funcprop(int s) { writeln("calling the setter with ", s); return a = s; } void main() { funcprop = 40; funcprop += 10; } === run: calling the setter with 40 calling the getter and getting 40 calling the setter with 50 Looks right to me. Now I just have to check for the property tag on some of these rewrites and then clean it up and test for a pull request.

It would be cool http://forum.dlang.org/thread/xcbweciovapinaicxgbn forum.dlang.org and http://d.puremagic.com/issues/show_bug.cgi?id=8006
Aug 06 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Jos=E9_Armando_Garc=EDa_Sancio?= <jsancio gmail.com> writes:
On Sun, Aug 5, 2012 at 2:32 PM, Kapps <opantm2+spam gmail.com> wrote:
 On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
 I'd be very surprised if all that many people compile with -property.

Indeed. Sometimes I try it just to see what happens, and always the same results: it doesn't solve problems and complains about code. Some examples of things that break: import std.algorithm; foreach(i; [1,2,3].map!"a+1") { } prophate.d(5): Error: not a property [1,2,3].map!("a+1") Of course, this is relatively new, using ufcs in 2.059, so the breakage probably isn't too bad, but I'm not the only one who writes it this way - I've seen a number of reddit and newsgroup comments do this too, especially when chaining it. [snip]

I completely agree, particularl with the UFCS part. UFCS is designed to get rid of the horrible mess of (), and now we want to arbitrarily force a () anyways? Seems like it defeats the purpose. To me, when comparing range.filter!"a > 2".map!"a*a".countUntil(3) to range.filter!"a > 2"().map!"a*a"().countUntil(3) Those extra paranthesis just don't do anything, they don't give extra meaning, they don't accomplish anything useful but distract from the actual expression.

Just a small comment. I have been following this thread a little and was somewhat surprise that the argument against enforcing parenthesis on non-properties is that a call like [1,2,3].map!"a+1" would look ugly as [1,2,3].map!"a+1"(). To me that is a issue of the std.algorithm module and not so much of the language. Personally I am not a huge fan of using strings as a way to pass a function into a high-order function. I suspect that this string stuff became popular because D didn't have lambda declarations and type inference when the module was designed and implemented. I wonder if the module signatures would look different if you designed it to use the current features of D. To be honest, when first saw 'some_array.map!"a+1"()' a few years back when I first learned about D my knee jerk reaction was: "from where in the world is 'a' coming from?". I remember I had to read std/algorithm.d and whatever module implements unary "string" functions to figure out what was going on. Anyways, I digress. Part of me looks forward to the day that I can use D reliably another part of my wants to just wait for Rust to hopefully get it "right". Thanks, -Jose
Aug 06 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--047d7b60399c3909ac04c6a725d5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 6, 2012 at 11:59 PM, Jos=E9 Armando Garc=EDa Sancio <
jsancio gmail.com> wrote:

 On Sun, Aug 5, 2012 at 2:32 PM, Kapps <opantm2+spam gmail.com> wrote:
 On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
 I'd be very surprised if all that many people compile with -property.

Indeed. Sometimes I try it just to see what happens, and always the sa=



 results: it doesn't solve problems and complains about code.

 Some examples of things that break:

 import std.algorithm;
 foreach(i; [1,2,3].map!"a+1") {

 }
 prophate.d(5): Error: not a property [1,2,3].map!("a+1")


 Of course, this is relatively new, using ufcs in 2.059, so the breakag=



 probably isn't too bad, but I'm not the only one who writes it this wa=



 -
 I've seen a number of reddit and newsgroup comments do this too,


 when chaining it.
 [snip]

I completely agree, particularl with the UFCS part. UFCS is designed to

 rid of the horrible mess of (), and now we want to arbitrarily force a =


 anyways? Seems like it defeats the purpose. To me, when comparing
 range.filter!"a > 2".map!"a*a".countUntil(3)
 to
 range.filter!"a > 2"().map!"a*a"().countUntil(3)
 Those extra paranthesis just don't do anything, they don't give extra
 meaning, they don't accomplish anything useful but distract from the

 expression.

Just a small comment. I have been following this thread a little and was somewhat surprise that the argument against enforcing parenthesis on non-properties is that a call like [1,2,3].map!"a+1" would look ugly as [1,2,3].map!"a+1"(). To me that is a issue of the std.algorithm module and not so much of the language. Personally I am not a huge fan of using strings as a way to pass a function into a high-order function. I suspect that this string stuff became popular because D didn't have lambda declarations and type inference when the module was designed and implemented. I wonder if the module signatures would look different if you designed it to use the current features of D. To be honest, when first saw 'some_array.map!"a+1"()' a few years back when I first learned about D my knee jerk reaction was: "from where in the world is 'a' coming from?". I remember I had to read std/algorithm.d and whatever module implements unary "string" functions to figure out what was going on. Anyways, I digress. Part of me looks forward to the day that I can use D reliably another part of my wants to just wait for Rust to hopefully get it "right". Thanks, -Jose

There was a pull to switch std.algorithm over to the new lambda syntax (by me). It caused the dmd unit tests to fail though. There is also an issue with intermodule visibility of nested structs that popped up and prevented the every function from being switched over. I should probably recreate the pull request so one of the compiler guys can take a look. BA --047d7b60399c3909ac04c6a725d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 6, 2012 at 11:59 PM, Jos=E9 Armando Garc=EDa Sancio <span dir= =3D"ltr">&lt;<a href=3D"mailto:jsancio gmail.com" target=3D"_blank">jsancio= gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid= ;padding-left:1ex"> <div class=3D"im">On Sun, Aug 5, 2012 at 2:32 PM, Kapps &lt;<a href=3D"mail= to:opantm2%2Bspam gmail.com">opantm2+spam gmail.com</a>&gt; wrote:<br> &gt; On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:<br> &gt;&gt;<br> &gt;&gt; On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:<= br> &gt;&gt;&gt;<br> &gt;&gt;&gt; I&#39;d be very surprised if all that many people compile with= -property.<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt; Indeed. Sometimes I try it just to see what happens, and always th= e same<br> &gt;&gt; results: it doesn&#39;t solve problems and complains about code.<b= r> &gt;&gt;<br> &gt;&gt; Some examples of things that break:<br> &gt;&gt;<br> &gt;&gt; import std.algorithm;<br> &gt;&gt; foreach(i; [1,2,3].map!&quot;a+1&quot;) {<br> &gt;&gt;<br> &gt;&gt; }<br> &gt;&gt; prophate.d(5): Error: not a property [1,2,3].map!(&quot;a+1&quot;)= <br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt; Of course, this is relatively new, using ufcs in 2.059, so the bre= akage<br> &gt;&gt; probably isn&#39;t too bad, but I&#39;m not the only one who write= s it this way -<br> &gt;&gt; I&#39;ve seen a number of reddit and newsgroup comments do this to= o, especially<br> &gt;&gt; when chaining it.<br> &gt;&gt; [snip]<br> &gt;<br> &gt;<br> &gt; I completely agree, particularl with the UFCS part. UFCS is designed t= o get<br> &gt; rid of the horrible mess of (), and now we want to arbitrarily force a= ()<br> &gt; anyways? Seems like it defeats the purpose. To me, when comparing<br> &gt; range.filter!&quot;a &gt; 2&quot;.map!&quot;a*a&quot;.countUntil(3)<br=

&gt; range.filter!&quot;a &gt; 2&quot;().map!&quot;a*a&quot;().countUntil(3= )<br> &gt; Those extra paranthesis just don&#39;t do anything, they don&#39;t giv= e extra<br> &gt; meaning, they don&#39;t accomplish anything useful but distract from t= he actual<br> &gt; expression.<br> &gt;<br> <br> </div>Just a small comment. I have been following this thread a little and<= br> was somewhat surprise that the argument against enforcing parenthesis<br> on non-properties is that a call like [1,2,3].map!&quot;a+1&quot; would loo= k<br> ugly as [1,2,3].map!&quot;a+1&quot;(). To me that is a issue of the<br> std.algorithm module and not so much of the language.<br> <br> Personally I am not a huge fan of using strings as a way to pass a<br> function into a high-order function. I suspect that this string stuff<br> became popular because D didn&#39;t have lambda declarations and type<br> inference when the module was designed and implemented. I wonder if<br> the module signatures would look different if you designed it to use<br> the current features of D.<br> <br> To be honest, when first saw &#39;some_array.map!&quot;a+1&quot;()&#39; a f= ew years back<br> when I first learned about D my knee jerk reaction was: &quot;from where in= <br> the world is &#39;a&#39; coming from?&quot;. I remember I had to read<br> std/algorithm.d and whatever module implements unary &quot;string&quot;<br> functions to figure out what was going on. Anyways, I digress.<br> <br> Part of me looks forward to the day that I can use D reliably another<br> part of my wants to just wait for Rust to hopefully get it &quot;right&quot= ;.<br> <br> Thanks,<br> -Jose<br> </blockquote></div><br><div>There was a pull to switch std.algorithm over t= o the new lambda syntax (by me). =A0It caused the dmd unit tests to fail th= ough. =A0There is also an issue with intermodule visibility of nested struc= ts that popped up and prevented the every function from being switched over= . =A0I should probably recreate the pull request so one of the compiler guy= s can take a look.</div> <div><br></div><div>BA</div> --047d7b60399c3909ac04c6a725d5--
Aug 06 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Jos=E9_Armando_Garc=EDa_Sancio?= <jsancio gmail.com> writes:
On Mon, Aug 6, 2012 at 11:31 PM, Brad Anderson <eco gnuk.net> wrote:
 On Mon, Aug 6, 2012 at 11:59 PM, Jos=E9 Armando Garc=EDa Sancio
 <jsancio gmail.com> wrote:
 On Sun, Aug 5, 2012 at 2:32 PM, Kapps <opantm2+spam gmail.com> wrote:
 On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
 I'd be very surprised if all that many people compile with -property=





 Indeed. Sometimes I try it just to see what happens, and always the
 same
 results: it doesn't solve problems and complains about code.

 Some examples of things that break:

 import std.algorithm;
 foreach(i; [1,2,3].map!"a+1") {

 }
 prophate.d(5): Error: not a property [1,2,3].map!("a+1")


 Of course, this is relatively new, using ufcs in 2.059, so the breaka=




 probably isn't too bad, but I'm not the only one who writes it this w=




 -
 I've seen a number of reddit and newsgroup comments do this too,
 especially
 when chaining it.
 [snip]

I completely agree, particularl with the UFCS part. UFCS is designed t=



 get
 rid of the horrible mess of (), and now we want to arbitrarily force a
 ()
 anyways? Seems like it defeats the purpose. To me, when comparing
 range.filter!"a > 2".map!"a*a".countUntil(3)
 to
 range.filter!"a > 2"().map!"a*a"().countUntil(3)
 Those extra paranthesis just don't do anything, they don't give extra
 meaning, they don't accomplish anything useful but distract from the
 actual
 expression.

Just a small comment. I have been following this thread a little and was somewhat surprise that the argument against enforcing parenthesis on non-properties is that a call like [1,2,3].map!"a+1" would look ugly as [1,2,3].map!"a+1"(). To me that is a issue of the std.algorithm module and not so much of the language. Personally I am not a huge fan of using strings as a way to pass a function into a high-order function. I suspect that this string stuff became popular because D didn't have lambda declarations and type inference when the module was designed and implemented. I wonder if the module signatures would look different if you designed it to use the current features of D. To be honest, when first saw 'some_array.map!"a+1"()' a few years back when I first learned about D my knee jerk reaction was: "from where in the world is 'a' coming from?". I remember I had to read std/algorithm.d and whatever module implements unary "string" functions to figure out what was going on. Anyways, I digress. Part of me looks forward to the day that I can use D reliably another part of my wants to just wait for Rust to hopefully get it "right". Thanks, -Jose

There was a pull to switch std.algorithm over to the new lambda syntax (b=

 me).  It caused the dmd unit tests to fail though.  There is also an issu=

 with intermodule visibility of nested structs that popped up and prevente=

 the every function from being switched over.  I should probably recreate =

 pull request so one of the compiler guys can take a look.

 BA

Wow. That would be nice! I would like to see such a change though I assume that such a change would break a lot of code. No?
Aug 06 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, August 06, 2012 23:44:21 Jos=C3=A9 Armando Garc=C3=ADa Sanci=
o wrote:
 Wow. That would be nice! I would like to see such a change though I
 assume that such a change would break a lot of code. No?

No. Both the string syntax and the new lambda syntax are here to stay. = Both=20 work now, and both will continue to work. The pull request was switchin= g over=20 most of the examples, not changing the functionality. - Jonathan M Davis
Aug 06 2012
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 7 August 2012 at 06:31:46 UTC, Brad Anderson wrote:
 On Mon, Aug 6, 2012 at 11:59 PM, José Armando García Sancio <
 jsancio gmail.com> wrote:

 Personally I am not a huge fan of using strings as a way to 
 pass a
 function into a high-order function. I suspect that this 
 string stuff
 became popular because D didn't have lambda declarations and 
 type
 inference when the module was designed and implemented. I 
 wonder if
 the module signatures would look different if you designed it 
 to use
 the current features of D.

 To be honest, when first saw 'some_array.map!"a+1"()' a few 
 years back
 when I first learned about D my knee jerk reaction was: "from 
 where in
 the world is 'a' coming from?". I remember I had to read
 std/algorithm.d and whatever module implements unary "string"
 functions to figure out what was going on. Anyways, I digress.

 Part of me looks forward to the day that I can use D reliably 
 another
 part of my wants to just wait for Rust to hopefully get it 
 "right".

 Thanks,
 -Jose

There was a pull to switch std.algorithm over to the new lambda syntax (by me). It caused the dmd unit tests to fail though. There is also an issue with intermodule visibility of nested structs that popped up and prevented the every function from being switched over. I should probably recreate the pull request so one of the compiler guys can take a look. BA

https://github.com/D-Programming-Language/phobos/pull/744
Aug 07 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Jos=E9_Armando_Garc=EDa_Sancio?= <jsancio gmail.com> writes:
On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 08/07/2012 07:59 AM, Jos=E9 Armando Garc=EDa Sancio wrote:
 On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam gmail.com>  wrote:
 On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
 I'd be very surprised if all that many people compile with -property.

Indeed. Sometimes I try it just to see what happens, and always the sa=




 results: it doesn't solve problems and complains about code.

 Some examples of things that break:

 import std.algorithm;
 foreach(i; [1,2,3].map!"a+1") {

 }
 prophate.d(5): Error: not a property [1,2,3].map!("a+1")


 Of course, this is relatively new, using ufcs in 2.059, so the breakag=




 probably isn't too bad, but I'm not the only one who writes it this wa=




 -
 I've seen a number of reddit and newsgroup comments do this too,
 especially
 when chaining it.
 [snip]

I completely agree, particularl with the UFCS part. UFCS is designed to get rid of the horrible mess of (), and now we want to arbitrarily force a =



 anyways? Seems like it defeats the purpose. To me, when comparing
 range.filter!"a>  2".map!"a*a".countUntil(3)
 to
 range.filter!"a>  2"().map!"a*a"().countUntil(3)
 Those extra paranthesis just don't do anything, they don't give extra
 meaning, they don't accomplish anything useful but distract from the
 actual
 expression.

Just a small comment. I have been following this thread a little and was somewhat surprise that the argument against enforcing parenthesis on non-properties is that a call like [1,2,3].map!"a+1" would look ugly as [1,2,3].map!"a+1"(). To me that is a issue of the std.algorithm module and not so much of the language. Personally I am not a huge fan of using strings as a way to pass a function into a high-order function. I suspect that this string stuff became popular because D didn't have lambda declarations and type inference when the module was designed and implemented.

String lambdas would quite certainly have been left out. Anyway, string lambdas are unrelated to the discussion of std.algorithm idioms in this context. [1,2,3].map!(a=3D>a+1) [1,2,3].map!(a=3D>a+1)()

Yep. The "problem" is not string lambda but that the mapping function is passed a template argument (which you need for string lambda to work). I guess that this is nice because you can alias the template or pass multiple lambdas (a little obscure but okay). If the lambda function was passed as a runtime parameter and not a template parameter can just do: [1, 2, 3].map(a=3D>a+1) If this was the case we wouldn't be talking about this non-property vs property with regard to map. I other words the map signature could look as follow (pseudo-code): Range!T map(T, U)(Range!U range, T delegate(U)); Thanks, -Jose P.S. You can still alias the map using a closure that binds the delegate but I digress.
Aug 07 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Jos=E9_Armando_Garc=EDa_Sancio?= <jsancio gmail.com> writes:
On Tue, Aug 7, 2012 at 12:27 PM, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 08/07/2012 08:37 PM, Jos=E9 Armando Garc=EDa Sancio wrote:
 On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr<timon.gehr gmx.ch>  wrote:
 On 08/07/2012 07:59 AM, Jos=E9 Armando Garc=EDa Sancio wrote:

 On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam gmail.com>   wrote:
 On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:
 I'd be very surprised if all that many people compile with -propert=







 Indeed. Sometimes I try it just to see what happens, and always the
 same
 results: it doesn't solve problems and complains about code.

 Some examples of things that break:

 import std.algorithm;
 foreach(i; [1,2,3].map!"a+1") {

 }
 prophate.d(5): Error: not a property [1,2,3].map!("a+1")


 Of course, this is relatively new, using ufcs in 2.059, so the
 breakage
 probably isn't too bad, but I'm not the only one who writes it this
 way
 -
 I've seen a number of reddit and newsgroup comments do this too,
 especially
 when chaining it.
 [snip]

I completely agree, particularl with the UFCS part. UFCS is designed =





 get
 rid of the horrible mess of (), and now we want to arbitrarily force =





 ()
 anyways? Seems like it defeats the purpose. To me, when comparing
 range.filter!"a>   2".map!"a*a".countUntil(3)
 to
 range.filter!"a>   2"().map!"a*a"().countUntil(3)
 Those extra paranthesis just don't do anything, they don't give extra
 meaning, they don't accomplish anything useful but distract from the
 actual
 expression.

Just a small comment. I have been following this thread a little and was somewhat surprise that the argument against enforcing parenthesis on non-properties is that a call like [1,2,3].map!"a+1" would look ugly as [1,2,3].map!"a+1"(). To me that is a issue of the std.algorithm module and not so much of the language. Personally I am not a huge fan of using strings as a way to pass a function into a high-order function. I suspect that this string stuff became popular because D didn't have lambda declarations and type inference when the module was designed and implemented.

String lambdas would quite certainly have been left out. Anyway, string lambdas are unrelated to the discussion of std.algorithm idioms in this context. [1,2,3].map!(a=3D>a+1) [1,2,3].map!(a=3D>a+1)()

Yep. The "problem" is not string lambda but that the mapping function is passed a template argument (which you need for string lambda to work).

It is also a matter of execution speed and GC pressure. None of the D compilers is able to inline delegate parameters at least as well as alias template parameters afaik. Furthermore, only the current form can _guarantee_ that no hidden GC allocations take place due to parameter passing to map.

Interesting. I can't speak for the GC and allocation you mention since I never tried to implement this myself but I should point out that C++ STL's algorithm "module" (transform, for_each, etc) works this way. Having said that, if D can't infer the type of lambda parameters (which I thought the current version of D could) and create a function/delegate based on the body then this is a no go. Thanks for you insight. -Jose
Aug 07 2012
prev sibling parent =?ISO-8859-1?Q?Jos=E9_Armando_Garc=EDa_Sancio?= <jsancio gmail.com> writes:
On Tue, Aug 7, 2012 at 1:52 PM, Jos=E9 Armando Garc=EDa Sancio
<jsancio gmail.com> wrote:
 On Tue, Aug 7, 2012 at 12:27 PM, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 08/07/2012 08:37 PM, Jos=E9 Armando Garc=EDa Sancio wrote:
 On Tue, Aug 7, 2012 at 10:39 AM, Timon Gehr<timon.gehr gmx.ch>  wrote:
 On 08/07/2012 07:59 AM, Jos=E9 Armando Garc=EDa Sancio wrote:

 On Sun, Aug 5, 2012 at 2:32 PM, Kapps<opantm2+spam gmail.com>   wrote=





 On Sunday, 5 August 2012 at 14:32:50 UTC, Adam D. Ruppe wrote:
 On Sunday, 5 August 2012 at 04:12:23 UTC, Jonathan M Davis wrote:






I never tried to implement this myself but I should point out that C++ STL's algorithm "module" (transform, for_each, etc) works this way. Having said that, if D can't infer the type of lambda parameters (which I thought the current version of D could) and create a function/delegate based on the body then this is a no go. Thanks for you insight. -Jose

Just incase it is not clear. I have zero interest in changing or promoting that we change the signature of the std.algorithm module. This is more of a selfish module design exercise on my part. Thanks, -Jose
Aug 07 2012