Is this a bugs ?

==============
struct A {
        ref auto opCall(string tmp) scope return {
                return this;
        }
}

struct B {
        A _a;

        @property ref auto a() scope return {
                return _a;
        }
}

extern(C) int main(){
        A a;
        a("a")("b");
        B b;
        b.a("a")("b");  // Error: function test_opCall.B.a() is not callable using argument types (string)
        return 0;
}
==========


I has to use  b.a()("a")("b") to avoid the compiler error. I think it should work to avoid the unnecessary ()

Should I submit a bugs ?

On Monday, 9 March 2020 at 09:25:31 UTC, Calvin P wrote:
> Is this a bugs ?
>
> ==============
> struct A {
>         ref auto opCall(string tmp) scope return {
>                 return this;
>         }
> }
>
> struct B {
>         A _a;
>
>         @property ref auto a() scope return {
>                 return _a;
>         }
> }
>
> extern(C) int main(){
>         A a;
>         a("a")("b");
>         B b;
>         b.a("a")("b");  // Error: function test_opCall.B.a() is not callable using argument types (string)
>         return 0;
> }
> ==========
>
>
> I has to use  b.a()("a")("b") to avoid the compiler error. I think it should work to avoid the unnecessary ()
>
> Should I submit a bugs ?

As written on https://dlang.org/spec/function.html#property-functions:

> WARNING: The definition and usefulness of property functions is being reviewed, and the implementation is currently incomplete. Using property functions is not recommended until the definition is more certain and implementation more mature.

So no, I don't think it's necessary to file a bug - we're aware they're somewhat wonky, and until a resolution has been agreed on, I don't think filing bugs on what's undecided behavior is worth it.

--
  Simen

On Monday, 9 March 2020 at 09:44:40 UTC, Simen Kjærås wrote:
> As written on https://dlang.org/spec/function.html#property-functions:
>
>> WARNING: The definition and usefulness of property functions is being reviewed, and the implementation is currently incomplete. Using property functions is not recommended until the definition is more certain and implementation more mature.
>
> So no, I don't think it's necessary to file a bug - we're aware they're somewhat wonky, and until a resolution has been agreed on, I don't think filing bugs on what's undecided behavior is worth it.
>
> --
>   Simen

Thanks for your reply.

@property exists so many years,   Druntime & Phobos use it  2280 times. I can't believe it is not recommended.

Is there any discuss link or documents about the review process?

On Monday, 9 March 2020 at 10:09:56 UTC, Calvin P wrote:
> @property exists so many years,   Druntime & Phobos use it  2280 times. I can't believe it is not recommended.

They never implemented it right. This opCall type thing was THE case we brought up to introduce @property in the first place.... but it never actually affected this.

For years, @property did absolutely nothing. We were told to use it for the future. Some people tried to put on a compiler switch to make it do something, but they consistently made that switch do the wrong thing! Then @property got frozen for fear of broken changes. LOL.

Now @property changes the result of `typeof(a.prop)`... but nothing else.

@property is one of the biggest WTFs of D's development.

Here's a wiki page referencing one of the 2013 discussions https://wiki.dlang.org/Property_Discussion_Wrap-up

though i'll note the thing is older than that.

What especially drove me nuts is people would so often say "property *syntax*" instead of "property semantics" - everyone would go on and on and on about banning optional parenthesis which should be a totally unrelated discussion when we should have been talking about the semantic question and focusing on the case you discovered - the case that actually matters.

On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote:
> On Monday, 9 March 2020 at 10:09:56 UTC, Calvin P wrote:
>> @property exists so many years,   Druntime & Phobos use it  2280 times. I can't believe it is not recommended.
>
> They never implemented it right. This opCall type thing was THE case we brought up to introduce @property in the first place.... but it never actually affected this.
>
> For years, @property did absolutely nothing. We were told to use it for the future. Some people tried to put on a compiler switch to make it do something, but they consistently made that switch do the wrong thing! Then @property got frozen for fear of broken changes. LOL.
>
> Now @property changes the result of `typeof(a.prop)`... but nothing else.
>
> @property is one of the biggest WTFs of D's development.

no kidding, d should just copy c# property semantics as the current implementation of it is wonky.

Mike attempted to add binary operations to it, but instead close his dip pull request and the following dmd pull requested.

-Alex

On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote:
> Here's a wiki page referencing one of the 2013 discussions https://wiki.dlang.org/Property_Discussion_Wrap-up
>
> though i'll note the thing is older than that.
>
> What especially drove me nuts is people would so often say "property *syntax*" instead of "property semantics" - everyone would go on and on and on about banning optional parenthesis which should be a totally unrelated discussion when we should have been talking about the semantic question and focusing on the case you discovered - the case that actually matters.


Thanks for reply.

after read the wiki, I am try answer some question.

>  Some people find it difficult to decide if something is a property or a function

> How can we get the getter / setter functions? Do we need to get those?

This can be fixed with a new __traits. and should allow get getter/setter functions.


> Some people think the additional @property attribute clutters the source code

I think it made code more readable.

> Can we get a reference to the property? What does &x.property_ mean?

this should be decide base the Getter function attribute,  ref function should allow get reference.   ref scope function allow get scope ref.

 > What is the type of the property? Return type, setter function type or getter function type? How to get the other types?

I think setter should force return void,   typeof(@property) should return getter return type, if no getter should return void.

> What does x.property_++ do?

this should only allow for ref getter with a setter.

> Is returning ref values from the getter OK?

 returning ref values from getter should be allowed.

I find one nice use case will be create a scope ref @property base on pointer filed.

struct A {
     B* _ptr;
    @property ref auto b() return scope
    {
        return *_ptr;
    }
}


> Is taking ref values in the setter OK?

I think no harm to allow this.

> UCFS and @property

If can not avoid conflict with UCFS, we can force @property only work for class|struct instance method function.

> How many parameters are allowed for property functions?

limit to 1 parameter.  use backtrace for caller position.

> Are templated properties allowed?

I think better not allow templated properties to keep it simple.

> Ambiguous / complicated if a function returns a delegate or similar (solvable with special case rules)
> Complicates semantics for human reader of the code (see comments about readability in "How those are (not!) related")

I can not answer this.  but I think a simple rule can be apply to @property:

When there is conflict,  treat it like field, not function.

base on this rule, I think getter function should be @nogc, no memory alloc.

On 09.03.20 13:14, Adam D. Ruppe wrote:
> 
> Here's a wiki page referencing one of the 2013 discussions https://wiki.dlang.org/Property_Discussion_Wrap-up

https://wiki.dlang.org/DIP24

On Monday, 9 March 2020 at 19:10:54 UTC, Timon Gehr wrote:
> https://wiki.dlang.org/DIP24

Hi , Timon Gehr

Thanks for the reply, very good DIPS.

I think this is very basic work, why the core team not take care it for such a long time.