Property functions are used wrong by a compiler when it needs to get and set a value at the same time:

import std.stdio;

struct A {
    @property int value() const {
        return value_;
    }

    @property ref int value(int v) {
		value_ = v;
		return value_;
    }

private:
	int value_;
}

int main(string[] args) {
	A a;
	a.value += 20; // <<<<< Error: a.value() is not an lvalue
	return 0;
}


It's a very inconvenient. Why don't just call a getter and then a setter functions in such cases?
I found the D language specification and it doesn't bother to explain how properties should behave in such cases. Is there a full language specification somewhere?
Also, I've googled a little and found a similar topic from 2012 (http://forum.dlang.org/thread/srhwzxgpiqucknchenot@forum.dlang.org). So, since 2012 nobody cared about it? What a shame!
Even a D Wiki page with properties discussion (https://wiki.dlang.org/Property_Discussion_Wrap-up) gives an example of property usage, which can't be compiled by the latest version of dmd:

a.weeks++;
a.weeks -=2;

Is there a chance, that this weird behavior will be fixed in the near future? What can I do to help fix it?

On Tuesday, 5 July 2016 at 10:52:10 UTC, zodd wrote:
> Property functions are used wrong by a compiler when it needs to get and set a value at the same time:
>
> [...]



Try
 @property ref int value() {
		return value_;
    }

On Tuesday, 5 July 2016 at 11:02:11 UTC, Satoshi wrote:
> On Tuesday, 5 July 2016 at 10:52:10 UTC, zodd wrote:
>> Property functions are used wrong by a compiler when it needs to get and set a value at the same time:
>>
>> [...]
>
>
>
> Try
>  @property ref int value() {
> 		return value_;
>     }

What if I need a setter function? I would never bother with properties and just used the field itself otherwise.

On Tuesday, 5 July 2016 at 10:52:10 UTC, zodd wrote:
> It's a very inconvenient. Why don't just call a getter and then a setter functions in such cases?

'cause property specs aren't even finalized yet.

> Is there a chance, that this weird behavior will be fixed in the near future? What can I do to help fix it?

almost as much as you can expect snowfall in hell.

On Tuesday, 5 July 2016 at 12:45:33 UTC, ketmar wrote:
>> Is there a chance, that this weird behavior will be fixed in the near future? What can I do to help fix it?
>
> almost as much as you can expect snowfall in hell.

Why do you have so pessimistic opinion? Is D a perspective language to learn or it's stagnating and never be production ready?

D is being used productively by some companies, so I guess we can call it production-ready. This doesn't meant there are not rough corners. The language is being actively developed, and I see that some work is being done on those rough corners. However, keep in mind that:

1) Maybe what you perceive as a strong deficiency isn't seen as a top
priority for the D developers. This issue with properties, for instance, is
annoying (I agree with you!), but most of the time (if not ever) it can be
easily circumvented (as Satoshi has shown).

2) Sometimes, changing language features have subtle side effects, and the devs must take everything into account. A fix that looks obvious for us mere mortals can actually open a can of worms and introduce many new issues.

Hope this answers your quesiton,

LMB


On Tue, Jul 5, 2016 at 10:14 AM, zodd via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote:

> On Tuesday, 5 July 2016 at 12:45:33 UTC, ketmar wrote:
>
>> Is there a chance, that this weird behavior will be fixed in the near
>>> future? What can I do to help fix it?
>>>
>>
>> almost as much as you can expect snowfall in hell.
>>
>
> Why do you have so pessimistic opinion? Is D a perspective language to learn or it's stagnating and never be production ready?
>

On 7/5/16 6:52 AM, zodd wrote:

> Is there a chance, that this weird behavior will be fixed in the near
> future? What can I do to help fix it?

Properties do not support read-modify-write operations. You can return a reference, or return a wrapper type to enable the operations you want.

D does not support any of the normally-expected property rewrites that many languages do.

For example: a.b.c = 5 where b is a property may not do what you expect.

It has been suggested in the past to have this behavior, but I doubt it will happen. It's possible to write such mechanisms as a library, but I've never seen someone do it.

-Steve

On Tuesday, 5 July 2016 at 13:14:29 UTC, zodd wrote:
> Why do you have so pessimistic opinion?

it is realistic.

> Is D a perspective language to learn or it's stagnating and never be production ready?

what do you want here: "non-stagnating" or "production ready"? D is "production ready", and that means that D should be STABLE. we can't introduce features just 'cause they are cool. we can't even change the features without long and hard discussion. if we'll finalize property specs, we'll stick with it forever. and devs have many other things to do too, most of it for free and in their spare time. that's why finalizing properties is postponed, for undefined time.

you *can* workaround this limitation for now. it won't be the cleanest code in the world, but you can do it. hint: alias this + returning temporary struct with pointer.

and, of course, you can hire Walter or Andrei on a full time to implement the feature you want. otherwise -- this is minor thing, which, nevertheless, require a huge amout of design work. it is unlikely that language devs will drop all other things, and go design and implementing it. and DIP will not help much: W&A still should evaluate it, and it's almost as hard as writing it from scratch.

if this minor thing blocks you from using D... alas. otherwise, just make a workaroung and keep going. *eventually* this will be fixed, but you'd better don't wait for it.

On Tuesday, 5 July 2016 at 13:37:50 UTC, ketmar wrote:
> if this minor thing blocks you from using D... alas. otherwise, just make a workaroung and keep going. *eventually* this will be fixed, but you'd better don't wait for it.

No, this issue doesn't block me from using D. I'm asking because I encountered with a few things (like this one), which seems like they're a bit "unfinished".
For example:
http://forum.dlang.org/post/mailman.1463.1361561853.22503.digitalmars-d-learn@puremagic.com : "Don't use 'in', because it doesn't mean what it seems to mean, and it's not correctly implemented at the moment."
http://forum.dlang.org/post/lgqcjiuigsseoazirkor@forum.dlang.org - "cast `shared` away. yes, this is how you supposed to use it now: cast it away."

Reading topics like these doesn't add confidence. But don't get me wrong, I don't want to say that "D is unfinished" or "D has a bad design". I don't know it good enough to make such loud statements. I'm just trying to figure out what D is and how can I use it.

Answering your other question: I think that production ready language should have a "finished" design and its detailed description (not a basic overview of the features).

On Tuesday, 5 July 2016 at 13:37:50 UTC, ketmar wrote:
> you *can* workaround this limitation for now. it won't be the cleanest code in the world, but you can do it. hint: alias this + returning temporary struct with pointer.

Of course, I can. I have been creating a lot of such workarounds with C++ for years. And this is one of the flaws of C++ - for every simple task (like a delegate or properties) you need to create a workaround because C++ standardization Committee thinks that it shouldn't be a part of the language.