View mode: basic / threaded / horizontal-split · Log in · Help
November 19, 2012
@property needed or not needed?
I can create a function that is located in a class/struct or 
outside on its own without @property. If the function has the 
signature of a property, i.e., void f( T x ) or T f(), I can use 
it as if it is a property.

Example:

// main module
int g; // global in main module
void p(int a) { g = a; }
int p() { return g; }

main()
{
   p = 7; // OK
   int t = p; // OK, t = 7
}

In the example, there's no class or struct, so I assume p() is 
considered to be a property of the module, which seems to make 
some sense.

I also see that there's a compiler option "-property" that 
currently is not recognized, but is supposed to "enforce use of 
@property on property functions".

So what's up with @property? Is it being depreciated for being 
redundant, or will it later be strictly enforced, or is it to be 
optionally enforced through a compiler switch?

--rt
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 06:02:06 UTC, Rob T wrote:

>
> I also see that there's a compiler option "-property" that 
> currently is not recognized, but is supposed to "enforce use of 
> @property on property functions".
>
> So what's up with @property? Is it being depreciated for being 
> redundant, or will it later be strictly enforced, or is it to 
> be optionally enforced through a compiler switch?
>

I don't recall seeing anything about @property being deprecated. 
The intention of the -property switch is to, IIRC, ease the 
transition to the ultimate full-time enforcement of the @property 
attribute. Enforcement is off by default. At some point, it will 
be turned on by default at which point the -property switch will 
no longer be necessary. I usually compile with -property and 
AFAIK it is functioning as intended. I've gotten errors in the 
past when it was enabled.
November 19, 2012
Re: @property needed or not needed?
On Monday, November 19, 2012 07:02:03 Rob T wrote:
> So what's up with @property? Is it being depreciated for being
> redundant, or will it later be strictly enforced, or is it to be
> optionally enforced through a compiler switch?

It didn't used to be necessary, but there are ambiguities without it 
(particularly with regards to property functions which return delegates), and 
a number of people don't like the laxness of practically any function with a 
particular sort of signature being able to be used as a property function 
rather than it being part of the API. So, @property was introduced, but 
similar to override, it was decided that its enforcement would be phased in.
-property was introduced so that the compiler's enforcement of it could be 
sorted out (it's still very buggy) and so that everyone would have time to 
adjust their code so that it used @property correctly.

Now, how strict the enforcement will ultimately be is up for some debate. It 
needs to be the case that any @property function must be used as a property 
function in order to avoid the aforementioned ambiguities (so using parens 
will be illegal with @property functions), but there's quite a lot of 
dissension surrounding whether non-property functions should be callable as 
property functions (i.e. whether non-@property functions with the appropriate 
signature can be called without parens as is currently the case). Some of us 
consider it to be incredibly sloppy to allow it, whereas others find the idea 
of requiring parens to be extremely annoying (especially when dealing with 
UFCS). TDPL is somewhat ambiguous on the matter, and AFAIK, no official decision 
has been made.

- Jonathan M Davis
November 19, 2012
Re: @property needed or not needed?
On 11/19/12 1:02 AM, Rob T wrote:
> So what's up with @property?

It's a mistake on top of another. We need to redesign it to such that 
the keyword '@property' is only required in cases that otherwise would 
be ambiguous (functions returning functions).

Andrei
November 19, 2012
Re: @property needed or not needed?
On 11/19/12 1:16 AM, Jonathan M Davis wrote:
> On Monday, November 19, 2012 07:02:03 Rob T wrote:
>> So what's up with @property? Is it being depreciated for being
>> redundant, or will it later be strictly enforced, or is it to be
>> optionally enforced through a compiler switch?
>
> It didn't used to be necessary, but there are ambiguities without it
> (particularly with regards to property functions which return delegates),

I think we need to seriously revisit that. It's a corner case that hurts 
everyone everywhere.

> and
> a number of people don't like the laxness of practically any function with a
> particular sort of signature being able to be used as a property function
> rather than it being part of the API.

I think UFCS changes the playfield quite a lot. Code using UFCS looks a 
whole lot crappier with a bunch of arbitrary extra parens.


Andrei
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 06:53:46 UTC, Andrei Alexandrescu 
wrote:
> I think UFCS changes the playfield quite a lot. Code using UFCS 
> looks a whole lot crappier with a bunch of arbitrary extra 
> parens.
>
>
> Andrei

I'm making good use out of UFCS functions that work like 
properties, so to remain consistent with struct/class calling 
syntax, I would expect to have the ability to define functions 
that have property semantics at the module level.

I really think that modules should have properties anyway, and 
since I can do it, I am doing it, and it works great.

My guess is that if @property gets enforced, we'll see a lot of 
functions with empty parameter lists being defined as @property 
for the sole reason to get rid of having to type in the ().

--rt
November 19, 2012
Re: @property needed or not needed?
On Monday, November 19, 2012 09:16:29 Rob T wrote:
> My guess is that if @property gets enforced, we'll see a lot of
> functions with empty parameter lists being defined as @property
> for the sole reason to get rid of having to type in the ().

Which completely violates the concept of a property in the first place. It's 
intended to be an abstraction for a variable. Using @property just to get rid 
of parens would be like naming types with verbs instead of nouns. It's 
completely backwards.

- Jonathan M Davis
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 08:23:43 UTC, Jonathan M Davis 
wrote:
> On Monday, November 19, 2012 09:16:29 Rob T wrote:
>> My guess is that if @property gets enforced, we'll see a lot of
>> functions with empty parameter lists being defined as @property
>> for the sole reason to get rid of having to type in the ().
>
> Which completely violates the concept of a property in the 
> first place. It's
> intended to be an abstraction for a variable. Using @property 
> just to get rid
> of parens would be like naming types with verbs instead of 
> nouns. It's
> completely backwards.
>
> - Jonathan M Davis

I very much like the combination of UFCS, ranges and parens-free 
style which allows writing code like

iota(0, 1000000).map!(to!string).retro.take(50).retro[10].writeln;

So I like Andrei's idea to force @property only for those 
functions where it's absolutely necessary to fight ambiguity.
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 08:45:03 UTC, thedeemon wrote:
> On Monday, 19 November 2012 at 08:23:43 UTC, Jonathan M Davis 
> wrote:
>> On Monday, November 19, 2012 09:16:29 Rob T wrote:
>>> My guess is that if @property gets enforced, we'll see a lot 
>>> of
>>> functions with empty parameter lists being defined as 
>>> @property
>>> for the sole reason to get rid of having to type in the ().
>>
>> Which completely violates the concept of a property in the 
>> first place. It's
>> intended to be an abstraction for a variable. Using @property 
>> just to get rid
>> of parens would be like naming types with verbs instead of 
>> nouns. It's
>> completely backwards.
>>
>> - Jonathan M Davis
>
> I very much like the combination of UFCS, ranges and 
> parens-free style which allows writing code like
>
> iota(0, 
> 1000000).map!(to!string).retro.take(50).retro[10].writeln;
>
> So I like Andrei's idea to force @property only for those 
> functions where it's absolutely necessary to fight ambiguity.

I kind of agree with Jonathan here. @property really shines when 
you want to "add" an attribute to a struct. array "front", for 
example, is a perfect example of this. RefCounted's "payload" 
(IMO), is also a good example.

*Functions* that do actual operations, in particular, "retro", 
IMO, should not be properties.

"byLines", for example, is a member function, and not property. 
How is:
r.retro;
any better than
r.byLines()
?

At best, it makes it look like r has a built-in retro attribute, 
which is miss-leading.

--------
I'll admit I thought too it would be "convenient" to write 
".retro" without the parens, but let's face it, that'd be 
incorrect usage...
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 08:23:43 UTC, Jonathan M Davis 
wrote:
> Which completely violates the concept of a property in the 
> first place. It's
> intended to be an abstraction for a variable. Using @property 
> just to get rid
> of parens would be like naming types with verbs instead of 
> nouns. It's
> completely backwards.
>
> - Jonathan M Davis

I know what you are saying, but I know that most people will 
usually follow the path of least resistance, so if a lot of 
people really dislike typing in () all over the place and are 
given a way out, then they'll likely take it, so long as it won't 
matter in any significant way in terms of practicality.

Another case that I would say violates the property concept, is a 
getter property function that returns a non-const ref, and 
reusing the same property function as a setter (for cases where 
there's nothing to be done when setting). It is less work when 
you can get away with defining one property function that looks 
like two, even though it may be bad in some way, I expect it will 
be done often.

I suppose with @property enforcement in place, the compiler can 
be adjusted to prevent non-const ref return values for property 
getters. That would also make it a bit more difficult to specify 
@property just to get rid of typing ().

The big question is what do we gain and what do we lose from 
enforcements like this? It has to be worth doing, or it should 
not be done,

Personally, I think we're much better off not attempting to 
enforce coding style through restrictions that could be viewed as 
unnecessary.

--rt
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home