On Thursday, 8 October 2015 at 12:32:59 UTC, John Colvin wrote:
> On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
>> First beta for the 2.069.0 release.
>>
>> http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html
>>
>> Please report any bugs at https://issues.dlang.org
>>
>> -Martin
>
> Am I being dumb or does SYSCONFDIR do absolutely nothing...

https://issues.dlang.org/show_bug.cgi?id=15181

On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
> First beta for the 2.069.0 release.
>
> http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html
>
> Please report any bugs at https://issues.dlang.org
>
> -Martin

I just noticed that you added the beta to the main download page, nice move, probably overdue.  Has it increased the downloads much?  Maybe you should add a warning there, for those who may not know the meaning of a beta.

On Friday, 9 October 2015 at 09:32:05 UTC, Joakim wrote:
> downloads much?  Maybe you should add a warning there, for those who may not know the meaning of a beta.

If you're a coder you know what it means.
If you just started with programming probably it doesn't make any difference :)

On Thursday, 8 October 2015 at 07:25:36 UTC, Andrea Fontana wrote:
> On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:
>> On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
>>> [...]
>>
>> `The -property switch has been deprecated.` Does that mean @property has no effect anymore ?
>>
>> --Stephan
>
> From changelog:
>
> "The -property switch used to disallow calling non-properties without parentheses. The switch has not been used to build Phobos for some time now. So naturally, code that's incompatible with -property has found its way in. This means, the switch has effectively not been supported by D at large.
>
> Since the behaviour of the -property switch was not well-liked, it's been deprecated and made to have no effect when used."

Thanks to clear that up.

--Stephan

On Thursday, October 08, 2015 15:00:15 Martin Nowak via Digitalmars-d-announce wrote:
> On Thursday, 8 October 2015 at 12:48:48 UTC, Adam D. Ruppe wrote:
> > On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:
> >> Does that mean @property has no effect anymore ?
> >
> > @property never actually worked anyway. It is still my hope that it will be correctly implemented some day though
>
> I think http://wiki.dlang.org/DIP23 reflects the most accurate roadmap for @property, basically being permissive w.r.t. parens. And who really cares whether it's rng.popFront or rng.popFront()?

What's problematic with regards to requiring parens or not is when the symbol _can't_ be called with parens. So, whether popFront is called with parens or not realistically doesn't matter, because it's going to be a function (theoretically, it could be a member variable that implements opCall, but that's so unlikely that there really is no need to worry about it IMHO). However, it _does_ matter whether something that's intended to be used as a property or not is called with parens. Code which uses parens on save or front is not going to work with all ranges, because they're not always functions. So - at least in templated code - it needs to be clear when a symbol is treated as a property, and it cannot be called with parens if it is supposed to be a property. Enforcing that @property is called without parens wouldn't entirely fix that problem, but it would help catch cases where someone actually used parens when they shouldn't have.

Regardless, what we pretty much need to do with @property at some point is make is that it's used to make it so that a single pair of parens operate on the return value rather than the function even if we don't do anything else with @property - otherwise properties which are delegates or other callables aren't possible. Having DIP 23 be implemented would be great though.

- Jonathan M Davis

On Saturday, 10 October 2015 at 01:27:09 UTC, Jonathan M Davis wrote:
> Regardless, what we pretty much need to do with @property at some point is make is that it's used to make it so that a single pair of parens operate on the return value rather than the function even if we don't do anything else with @property

Right, ideally a @proptery function can perfectly replace a variable, but practically calling the return value seems far fetched.
What would you use that for, a handwritten interface struct with function pointers made read-only using @property?

To me the whole property discussion looks like one of those endless debates about an insignificant detail.
Scala and Ruby seem to do well with sloppy parens.
With the introduction of UFCS it became clear that nobody likes byLine().array().sort().release(), and even less rng.release.sort().array().front.
For some functions it's really hard to decide whether or not something is a property, e.g. for me Range.save is an action/function not a property. So for me using @property appears to waste time making pointless decisions.

On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:
> What would you use that for, a handwritten interface struct with function pointers made read-only using @property?

var a = var.emptyObject; // works today
a.prop = { do_stuff; }; // works today
a.prop(); // useless no op
a.prop()(); // this is needed

That one case alone is all I care about @property for.

On Saturday, 10 October 2015 at 02:15:14 UTC, Adam D. Ruppe wrote:
> On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:
>> What would you use that for, a handwritten interface struct with function pointers made read-only using @property?
>
> var a = var.emptyObject; // works today
> a.prop = { do_stuff; }; // works today
> a.prop(); // useless no op
> a.prop()(); // this is needed
>
> That one case alone is all I care about @property for.

That's what I meant, weird use-case, at best it's a callback better/setter.
I've never written such code, but even if you would, the 2 pairs of parens are only a tiny problem for generic code, nothing to warrant the invasive language feature @property is.

On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
> nothing to warrant the invasive language feature @property is.

There's no reason for @property to be invasive. ALL it needs to do is handle that one case, it shouldn't even be used anywhere else. Everything else is trivial or irrelevant.

And the beauty of this is it won't even break any code.

On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
> That's what I meant, weird use-case, at best it's a callback better/setter.
> I've never written such code, but even if you would, the 2 pairs of parens are only a tiny problem for generic code, nothing to warrant the invasive language feature @property is.

I don't know how much metaprogramming-heavy generic code you've written, but I can say from first-hand experience that there is such a thing as Hell, and it is called Optional Parens.

Jokes aside, I've finally fixed (read: worked around using awful hacks) a bug where the compiler was complaining about either "Type.memberFunction is not callable with arguments ()" or "Need 'this' for Type.memberFunction". I love optional parens in regular code, especially range-based code (doesn't everybody?), but I desperately want a way to ensure that the symbol that I'm trying to pass to a template function won't be interpreted as a function call instead.