http://d.puremagic.com/issues/show_bug.cgi?id=7176


Artem Borisovskiy <kolos80@bk.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kolos80@bk.ru


--- Comment #10 from Artem Borisovskiy <kolos80@bk.ru> 2012-07-20 05:37:43 PDT ---
> class Foo
> {
>     @property int bar;
> }
> 
> Is lowered to this:
> 
> class Foo
> {
>     private int bar_;
> 
>     @property int bar () { return bar_; }
>     @property int bar (int value) { return bar_ = value; }
> }

Why not just make bar_ public? You do not add any code to the getter nor to the setter anyway.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #11 from Jacob Carlborg <doob@me.com> 2012-07-20 07:06:34 PDT ---
(In reply to comment #10)

> Why not just make bar_ public? You do not add any code to the getter nor to the setter anyway.

Perhaps I want it to be virtual, to be able to override it in a subclass.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #12 from David Piepgrass <qwertie256@gmail.com> 2012-07-20 08:59:15 PDT ---
(In reply to comment #11)
> (In reply to comment #10)
> > Why not just make bar_ public? You do not add any code to the getter nor to the setter anyway.
> 
> Perhaps I want it to be virtual, to be able to override it in a subclass.

Yes, or, quite often I want to write a trivial getter but a nontrivial setter. So I'd like just the getter for free. Also, when the interface is going to be exported, even a trivial property should often be a property instead of a field, to avoid breaking binary compatibility if one changes one's mind and wants to make it a property later (actually this even affects source compatibility--a property can't be passed by reference).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #13 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-07-20 10:06:53 PDT ---
> Yes, or, quite often I want to write a trivial getter but a nontrivial setter. So I'd like just the getter for free. Also, when the interface is going to be exported, even a trivial property should often be a property instead of a field, to avoid breaking binary compatibility if one changes one's mind and wants to make it a property later (actually this even affects source compatibility--a property can't be passed by reference).

That's why I've been tempted to suggest that @property on a variable made it so that only operations which would still be legal if it were switched to being a property function were allowed. I can't remember whether I ever actually opened an enhancement request on that though. I'd have to go digging to find out.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #14 from Jacob Carlborg <doob@me.com> 2012-07-20 10:22:44 PDT ---
(In reply to comment #12)

> Yes, or, quite often I want to write a trivial getter but a nontrivial setter. So I'd like just the getter for free. Also, when the interface is going to be exported, even a trivial property should often be a property instead of a field, to avoid breaking binary compatibility if one changes one's mind and wants to make it a property later (actually this even affects source compatibility--a property can't be passed by reference).

Other good points.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #15 from bearophile_hugs@eml.cc 2013-03-20 06:13:22 PDT ---
After having used Scala a little, I now have changed my mind a little again.

In Scala you write:

def f3(x: Int, y: Int): Int = if (x == 0) x else x * y


This is current valid D code:

int f1(int x, int y) { return (x == 0) ? x : x ^^ 2; }

const f2 = (int x, int y) => (x == 0) ? x : x ^^ 2;



Allowing this in D is nice to reduce some syntax noise. So I now like this idea:

int f4(int x, int y) => (x == 0) ? x : x ^^ 2;


In functional-style programming very short functions are common.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7176


Nick Treleaven <ntrel-public@yahoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ntrel-public@yahoo.co.uk


--- Comment #16 from Nick Treleaven <ntrel-public@yahoo.co.uk> 2013-03-20 07:15:30 PDT ---
(In reply to comment #7)
> I could really have a use for this. I have a lot of methods that just returns a single expression.

I thought I'd add some hard data on this. There are quite a lot of these in Phobos (edited results to only show larger count items):

$ git grep -Ec '\{\s*return\b' std/
std/algorithm.d:77
std/cpuid.d:27
std/format.d:35
std/functional.d:37
std/math.d:31
std/range.d:86
std/regex.d:44
std/traits.d:71
std/typecons.d:54
std/variant.d:23
std/xml.d:24

Admittedly, some of these may be false positives for e.g. lambdas, but a quick scan through the results shows they are almost all one line function/method definitions. I think this demonstrates a significant use case for the proposed syntax.

> Another idea would be to allow optional braces for methods and functions, just as for if-statements.

That might not be ideal syntax with template constraints:
void foo(T)(T v) if (isFoo!T) writeln(v);
void foo(T)(T v) if (isFoo!T) => writeln(v);

The second syntax is clearer in distinguishing the constraint from if statement syntax IMO.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #17 from Kenji Hara <k.hara.pg@gmail.com> 2013-03-20 08:21:44 PDT ---
I don't like this feature. Because:

1. it would reduce code readability.

   class LibClass {
     int foo() { return 1; }
     string bar() => "hi";
   }

   Mixing lambda syntax and normal function syntax looks messy.

2. Just only reducing 7 character is too small benefit.

   auto foo()=>expr;
   auto foo(){return expr;}

   With more complex function signature:

   ComplexReturnType!(..) foo(T, U, V)(T t, U u, V v) if (...)=>expr;
   ComplexReturnType!(..) foo(T, U, V)(T t, U u, V v) if (...){return expr;}

   Ratio will fall further.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7176



--- Comment #18 from timon.gehr@gmx.ch 2013-03-20 13:33:49 PDT ---
(In reply to comment #17)
> I don't like this feature. Because:
> 
> 1. it would reduce code readability.
> 

On the contrary! It also increases language consistency.

>    class LibClass {
>      int foo() { return 1; }
>      string bar() => "hi";
>    }
> 
>    Mixing lambda syntax and normal function syntax looks messy.
> 

No. It is normal function syntax that looks messy in this case.

class LibClass {
    auto foo() => 1;
    auto bar() => "hi";
}


> 2. Just only reducing 7 character is too small benefit.
> 

7*_N_ characters. Also, it can get rid of additional indentation.

>    auto foo()=>expr;
>    auto foo(){return expr;}
> 
>    With more complex function signature:
> 
>    ComplexReturnType!(..) foo(T, U, V)(T t, U u, V v) if (...)=>expr;
>    ComplexReturnType!(..) foo(T, U, V)(T t, U u, V v) if (...){return expr;}
> 
>    Ratio will fall further.

This is not a valid argument in any case.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------