digitalmars.D.learn - property with opCall
- Calvin P (25/25) Mar 09 2020 Is this a bugs ?
- Simen =?UTF-8?B?S2rDpnLDpXM=?= (9/38) Mar 09 2020 As written on
- Calvin P (5/17) Mar 09 2020 Thanks for your reply.
- Adam D. Ruppe (21/23) Mar 09 2020 They never implemented it right. This opCall type thing was THE
- 12345swordy (6/20) Mar 09 2020 no kidding, d should just copy c# property semantics as the
- Calvin P (34/61) Mar 09 2020 Thanks for reply.
- Timon Gehr (2/5) Mar 09 2020 https://wiki.dlang.org/DIP24
- Calvin P (5/6) Mar 10 2020 Hi , Timon Gehr
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 ?
Mar 09 2020
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
Mar 09 2020
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: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?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
Mar 09 2020
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.
Mar 09 2020
12345swordy <alexanderheistermann gmail.com> 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: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. -Alexproperty 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.
Mar 09 2020
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 functionHow 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 codeI 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 propertyIf 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.
Mar 09 2020
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-uphttps://wiki.dlang.org/DIP24
Mar 09 2020
On Monday, 9 March 2020 at 19:10:54 UTC, Timon Gehr wrote:https://wiki.dlang.org/DIP24Hi , 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.
Mar 10 2020