Re: property functions
On Sunday, 16 May 2021 at 15:47:55 UTC, Adam D. Ruppe wrote: On Sunday, 16 May 2021 at 15:12:25 UTC, Nick wrote: Is this warning still valid? The @property thing doesn't do much. All it does is change typeof(a.prop) from function over to the return value of the function. (Which actually makes it required for the range empty and front things!) But since it doesn't do much it makes it very easy to misuse it too - putting it somewhere where it doesn't belong will NOT cause the compiler to issue an error. So that's why it is warned: the current behavior is extremely minimal and if that expands and you misused it, you'll see broken code down the line. But on the other hand, @property has been a do-nothing for a decade now, so I wouldn't expect that to change any time soon. My general rule is to put it on something that should be replaceable with a public data member. If you can't do that, don't make it @property. In particular, do NOT put it on something for the sole reason of not using () on the call. @property is not really related to parenthesis syntax. Only use it when it is specifically meant to be replaceable with a public member. Thanks for the detailed explanation. I guess the wording of the warning seems strange to me, in that it recommends not to use property functions; but, in actuality (and regardless?), these functions are used a lot (even in the standard library; at least from what I've seen). Also, although this warning is delivered, there is nothing in the documentation that explicitly addresses a concrete downside (or recommended limitation) to using them. However, your explanation does provide some context to this warning.
Re: property functions
On Monday, 17 May 2021 at 14:56:21 UTC, Steven Schveighoffer wrote: It used to be required, but we removed that requirement a long time ago. yeah i remember ElementType required it last time i checked but that was a while ago indeed it is all fixed now
Re: property functions
On 5/16/21 11:47 AM, Adam D. Ruppe wrote: On Sunday, 16 May 2021 at 15:12:25 UTC, Nick wrote: Is this warning still valid? The @property thing doesn't do much. All it does is change typeof(a.prop) from function over to the return value of the function. (Which actually makes it required for the range empty and front things!) It used to be required, but we removed that requirement a long time ago. It was inconsistently applied (some features required @property, and some did not). -Steve
Re: property functions
On Sunday, 16 May 2021 at 15:47:55 UTC, Adam D. Ruppe wrote:
On Sunday, 16 May 2021 at 15:12:25 UTC, Nick wrote:
Is this warning still valid?
The @property thing doesn't do much. All it does is change
typeof(a.prop) from function over to the return value of the
function. (Which actually makes it required for the range empty
and front things!)
It's not required:
struct Example
{
int front() { return 42; }
bool empty() { return false; }
void popFront() {}
}
import std.range;
static assert(isInputRange!Example);
Re: property functions
On Sunday, 16 May 2021 at 15:12:25 UTC, Nick wrote: Is this warning still valid? The @property thing doesn't do much. All it does is change typeof(a.prop) from function over to the return value of the function. (Which actually makes it required for the range empty and front things!) But since it doesn't do much it makes it very easy to misuse it too - putting it somewhere where it doesn't belong will NOT cause the compiler to issue an error. So that's why it is warned: the current behavior is extremely minimal and if that expands and you misused it, you'll see broken code down the line. But on the other hand, @property has been a do-nothing for a decade now, so I wouldn't expect that to change any time soon. My general rule is to put it on something that should be replaceable with a public data member. If you can't do that, don't make it @property. In particular, do NOT put it on something for the sole reason of not using () on the call. @property is not really related to parenthesis syntax. Only use it when it is specifically meant to be replaceable with a public member.
property functions
The [Property Functions](https://dlang.org/spec/function.html#property-functions) documentation reads: 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. Is this warning still valid? The standard library appears to extensively use property functions.
with() statement doesn't want to work with property functions
struct Bar { int x; }
struct Foo
{
Bar _bar;
Bar bar()
{
return _bar;
}
}
void main()
{
Foo foo;
with (foo.bar)
{
}
}
Error: foo.bar() is not an lvalue
I've made a getter because I want to control how _bar is manipulated.
I've lost the ability to use the with statement, which is a minor
inconvenience. Is there a specific reason why with() should not be
allowed to be used with property functions?
This works fine:
immutable Foo foo;
with (foo)
{
}
So I don't see why it shouldn't work on property functions?
Re: with() statement doesn't want to work with property functions
On 09/18/2011 05:14 PM, Andrej Mitrovic wrote:
struct Bar { int x; }
struct Foo
{
Bar _bar;
Bar bar()
{
return _bar;
}
}
void main()
{
Foo foo;
with (foo.bar)
{
}
}
Error: foo.bar() is not an lvalue
I've made a getter because I want to control how _bar is manipulated.
I've lost the ability to use the with statement, which is a minor
inconvenience. Is there a specific reason why with() should not be
allowed to be used with property functions?
This works fine:
immutable Foo foo;
with (foo)
{
}
So I don't see why it shouldn't work on property functions?
It is that way because the implementation of with is still a quick hack.
I think it is implemented like this:
1. If the scope does not require a 'this' pointer, just do lookup
differently.
2. If the scope does require a 'this' pointer, declare a hidden pointer
to the value of the expression, and redirect all lookups that must be
performed on the expression to that pointer.
Obviously, if the address of the expression cannot be taken, the
compiler should actually store the expression in a hidden stack
variable. I think this is worth a bug report if it is not known already.
Re: Why non-@property functions don't need parentheses
It will be fixed at some point, but it hasn't been yet. Oh cool, all right; thanks!
Why non-@property functions don't need parentheses
Hi, I was wondering, why are we allowed to omit parentheses when calling functions with no arguments, when they are not @properties? Is there a good reason for relaxing the language rules like this? Thanks!
Re: Why non-@property functions don't need parentheses
On Sunday 06 February 2011 20:38:29 %u wrote: Hi, I was wondering, why are we allowed to omit parentheses when calling functions with no arguments, when they are not @properties? Is there a good reason for relaxing the language rules like this? Because the compiler is not in line with TDPL yet. It used to be that @property didn't even exist and _all_ functions which returned a value and took no parameters could be used as a getter property and _all_ functions which returned void and took a single value could be used as a setter property. @property was added so that it could be better controlled. However, while @property has been added, the compiler has yet to be changed to enforce that @property functions are called without parens and that non-@property functions are called with them. It will be fixed at some point, but it hasn't been yet. - Jonathan M Davis
Re: Why non-@property functions don't need parentheses
%u wfunct...@hotmail.com wrote: Hi, I was wondering, why are we allowed to omit parentheses when calling functions with no arguments, when they are not @properties? Is there a good reason for relaxing the language rules like this? This behavior is deprecated, but other features have had a higher priority than removing features that do not cause big trouble. :p -- Simen
