Re: Beta D 2.069.0-b1
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
Re: Beta D 2.069.0-b1
On Thursday, 8 October 2015 at 15:04:08 UTC, David Nadlinger wrote: On Thursday, 8 October 2015 at 15:01:31 UTC, Martin Nowak wrote: On Thursday, 8 October 2015 at 12:20:23 UTC, Andrea Fontana wrote: Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 2.068.2? The last released compiler, we don't have any bootstrap method (using a small C++ compiler or so). One does not exclude the other. You could still re-build 2.069b1 using itself. — David Sure, just to know which option is used. I think rebuilding 2.069b1 with 2.069b1 could help to find bugs and, of course, can takes advantages from the new improvements... am I missing something?
Re: Beta D 2.069.0-b1
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.
Re: Beta D 2.069.0-b1
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.
Re: Beta D 2.069.0-b1
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.
Re: Beta D 2.069.0-b1
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.
Re: Beta D 2.069.0-b1
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
Re: Beta D 2.069.0-b1
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.
Re: Beta D 2.069.0-b1
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.
Re: Beta D 2.069.0-b1
On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote: 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. Strict typing and explicitness has a real effect on code legibility and maintenance. D is trying too hard to be a scripting language. Taking away getter/setter typing just reinforce that impression. With the introduction of UFCS it became clear that nobody likes byLine().array().sort().release(), and even less rng.release.sort().array().front. Introduce a pipeline operator. Chaining processes with dot operators has always been an ugly old OO hack. 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. If it is hard to decide then that probably means that the model is flawed and needs more work. D really needs to start strengthening the type system, rather than eroding it.
Re: Beta D 2.069.0-b1
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 :)
Re: Walter and I talk about D in Romania
On Monday, 5 October 2015 at 14:10:43 UTC, Vladimir Panteleev wrote: On Friday, 2 October 2015 at 11:25:44 UTC, Andrei Alexandrescu wrote: Walter and I will travel to Brasov, Romania to hold an evening-long event on the D language. There's been strong interest in the event with over 300 registrants so far. http://curiousminds.ro Scott Meyers will guest star in a panel following the talks. We're all looking forward to it! Not going to miss this opportunity! I'm here! Who else is?
Re: Beta D 2.069.0-b1
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
