On 17.04.2016 19:39, QAston wrote:
> First @property + compiler switch, now @property + deprecated switch.
> When should I use property? For all the getters? Should I start with
> property or with member access? Does it even matter because of optional
> parens? Why do I even need to care about this?

@property is in a bad state right now. The behavior that used to be enabled by -property has been decided against, and now @property has only one effect that I can think of off the top of my head, and it's rather subtle:

----
int foo() {return 0;}
@property int bar() {return 0;}

pragma(msg, typeof(foo)); /* int() */
pragma(msg, typeof(bar)); /* int */

pragma(msg, typeof(&foo)); /* int function() ref */
pragma(msg, typeof(&bar)); /* int function() @property ref */
----

I don't think anyone is really happy with the current @property, but everyone is probably tired of discussing it.

On 17.04.2016 18:44, Nick Treleaven wrote:
> I think @property is OK.

No, it isn't:

import std.stdio;
struct S{
    @property int delegate() foo(){ return ()=>3; }
}

void main(){
    S s;
    writeln(s.foo()); // "int delegate()"
}

On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
> On 17.04.2016 18:44, Nick Treleaven wrote:
>> I think @property is OK.
>
> No, it isn't:


Seriously, @property is one of the biggest SNAFUs of the language.

I think I'll write an editorial about this stuff in TWID tonight. (I'm also very skeptical of the value of pure, @safe, nothrow, and @nogc)

On Sunday, 17 April 2016 at 23:03:26 UTC, Adam D. Ruppe wrote:
> On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
>> On 17.04.2016 18:44, Nick Treleaven wrote:
>>> I think @property is OK.
>>
>> No, it isn't:
>
>
> Seriously, @property is one of the biggest SNAFUs of the language.
>
> I think I'll write an editorial about this stuff in TWID tonight. (I'm also very skeptical of the value of pure, @safe, nothrow, and @nogc)

nothrow may be useful for passing callbacks in C functions.
shared currently is useless too tbw

On Sunday, 17 April 2016 at 23:03:26 UTC, Adam D. Ruppe wrote:
> On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
>> On 17.04.2016 18:44, Nick Treleaven wrote:
>>> I think @property is OK.
>>
>> No, it isn't:
>
>
> Seriously, @property is one of the biggest SNAFUs of the language.
>

Today I learned a new acronym. Fit @property perfectly.

On Sunday, 17 April 2016 at 23:03:26 UTC, Adam D. Ruppe wrote:
> On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
>> On 17.04.2016 18:44, Nick Treleaven wrote:
>>> I think @property is OK.
>>
>> No, it isn't:
>
>
> Seriously, @property is one of the biggest SNAFUs of the language.
>
> I think I'll write an editorial about this stuff in TWID tonight. (I'm also very skeptical of the value of pure, @safe, nothrow, and @nogc)

As a big user of @nogc, I'd disagree. @nogc is a bit hard to use and effectively split the language in two, but gives the absolute confidence that nothing will block.

In audio callbacks and you are supposed to use tryLock and atomics instead of locking, so allocating is a big problem. And it's very easy to let something passthrough like a rogue closure or an array literal.

@nogc is a big safety net I thought wasn't needed, until I had to make @nogc code.

Personnally I wish synchronized, comma operator, and actively harmful things would go. nothrow provides little value, but no negative value.

On Monday, 18 April 2016 at 08:52:19 UTC, Guillaume Piolat wrote:
> Personnally I wish synchronized, comma operator, and actively harmful things would go. nothrow provides little value, but no negative value.

And shared and @property :)
But I guess this isn't Christmas already.

On Saturday, 16 April 2016 at 11:49:21 UTC, Nick Treleaven wrote:
> On 16/04/2016 12:40, Marc Schütz wrote:
>> What are the plans for DIP25's `return` attribute? Because with it, the
>> compiler has enough information to know that the return value aliases `s`:
>>
>> const(T)[] replaceSlice(T)(const(T)[] s return, in T[] slice, in T[]
>> replacement);
>>
>> If the function is passed a mutable `s`, its return value can be
>> implicitly convertible to `T[]`.
>
> AIUI, functions don't have to return part of the parameter tagged with return, it can return anything.
>
> See:
> http://wiki.dlang.org/DIP25#Types_of_Result_vs._Parameters

I'm not sure. That section says that the situation may change in the future. Other parts of the DIP can be read both ways, but it doesn't mention aliasing explicitly. As this is currently still experimental and not a complete design anyway, we can change it to fit our needs.

On Monday, 18 April 2016 at 08:53:31 UTC, Guillaume Piolat wrote:
> And shared and @property :)

I still want to see @property fixed rather than removed - the edge case with returning a delegate is an interesting one to me (though that's ALL I want it to do, leave everything else alone)

On Sunday, 17 April 2016 at 17:39:48 UTC, QAston wrote:
> First @property + compiler switch, now @property + deprecated switch. When should I use property? For all the getters? Should I start with property or with member access? Does it even matter because of optional parens? Why do I even need to care about this?

Rationale behind DIP23 seems to make language usable without @property and provide a puristic feature for those who are into it and for one corner case.