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

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.

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

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

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

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

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

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.

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...

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