January 24, 2013 Re: @property - take it behind the woodshed and shoot it? - writefln | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | On Thu, Jan 24, 2013 at 4:53 PM, Nick Treleaven <ntrel-public@yahoo.co.uk> wrote: > write!"%s\n" = someExpression; > > :-p > > Seriously, it would be nice to have a compile-time checked format string for writefln. I made a stab at it in a template tutorial that can be found on github: https://github.com/PhilippeSigaud/D-templates-tutorial You can grab the pdf, it's on section 5.11, p. 168 (Statically-Checked Writeln) Use example: cwritefln!"For sample #%d, the results are (%s, %f)"( 0, "foo", 3.14); |
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Thursday, 24 January 2013 at 16:29:07 UTC, Andrei Alexandrescu wrote:
> On 1/24/13 3:57 AM, Jacob Carlborg wrote:
>> void delegate () foo ();
>>
>> foo() // would call the delegate ?
>
> Yes.
>
> a = foo; // fetch the delegate
> b = foo(); // fetch and invoke the delegate
How about generic code?
void callFunc(alias f, Args...)(Args args)
{
f(args);
}
void delegate() foo();
void delegate(int) bar(int x);
callFunc!foo(); // calls delegate?
callFunc!bar(0); // calls bar?
Seems like a recipe for disaster.
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Thu, 24 Jan 2013 02:34:42 -0600, Walter Bright <newshound2@digitalmars.com> wrote:
> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>
> Perhaps we should revert to a simple set of rules.
>
> 1. Empty parens are optional. If there is an ambiguity with the return value taking (), the () go on the return value.
>
> 2. the:
> f = g
> rewrite to:
> f(g)
> only happens if f is a function that only has overloads for () and (one argument). No variadics.
>
> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.
vote++
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to mist | On 1/24/13 6:50 AM, mist wrote: > I am probably I minority here but I liked the most strict -property > version and it made a lot of sense to me. Rationale is simple: > some().ufcs().chaining(); - this is just a minor syntax inconvenience It becomes way uglier with templates: some!(e1)().ufcs!(e2)().chaining!(e3)(). In fact look at the code written by Nick in _favor_ of the parens. Self-destruction at its finest. > anything; - this drives me crazy, there is no way to understand if this I was amazed at how quickly I got used to it. > a no-op statement variable of function call with some side-effect > I'd really like to have all function types to be obliged to use () and > use property syntax only to those of property semantics (no side-effect > variable getter/setter) > > But looking at other comments this does not seem popular :( Well, I can > only hope for something simple and non-revolutionary then. You'll still be able to use parens. Andrei |
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bernard Helyer | On 1/24/13 7:13 AM, Bernard Helyer wrote:
> On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
>> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>>
>> Perhaps we should revert to a simple set of rules.
>>
>> 1. Empty parens are optional. If there is an ambiguity with the return
>> value taking (), the () go on the return value.
>>
>> 2. the:
>> f = g
>> rewrite to:
>> f(g)
>> only happens if f is a function that only has overloads for () and
>> (one argument). No variadics.
>>
>> 3. Parens are required for calling delegates or function pointers.
>>
>> 4. No more @property.
>
> This is lazy design, plain and simple. You say it's turned into
> a monster, but @property, at its core, is simpler than the heuristics
> you've demonstrated here. To my mind, @property, properly implemented
> is simple:
>
> @property functions may be called with no parens or with assignment as
> the singular argument. Non @property functions may not.
>
> There. No complications. The only complications come from D's history.
> And then you want to turn it back? This seems a terrible idea -- the
> deed is done, pull the trigger. Make @property mandatory for property
> functions.
No. The complications come from the fact that (a) nobody could agree what should be a @property and what shouldn't; (b) @property adds noise for everybody for the sake of a corner case (functions returning delegates); (c) the @property discipline failed to align itself in any way with better code quality.
Andrei
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 1/24/13 8:01 AM, bearophile wrote:
> I think this silly fear of breaking user code was one of the main causes
> of the failure of @property in the first place.
No. @property is bad design, pure and simple. It's great that we're acknowledging that.
Andrei
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Thursday, 24 January 2013 at 17:51:32 UTC, Andrei Alexandrescu wrote:
> No. The complications come from the fact that (a) nobody could agree what should be a @property and what shouldn't; (b) @property adds noise for everybody for the sake of a corner case (functions returning delegates); (c) the @property discipline failed to align itself in any way with better code quality.
The simple(r) explanation is: The current *implementation* is broken.
David
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On 1/24/13 8:38 AM, Iain Buclaw wrote:
> On 24 January 2013 08:34, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@digitalmars.com>> wrote:
>
> This has turned into a monster. We've taken 2 or 3 wrong turns
> somewhere.
>
> Perhaps we should revert to a simple set of rules.
>
> 1. Empty parens are optional. If there is an ambiguity with the
> return value taking (), the () go on the return value.
>
> 2. the:
> f = g
> rewrite to:
> f(g)
> only happens if f is a function that only has overloads for () and
> (one argument). No variadics.
>
> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.
>
>
>
> As much as I want to agree, I also feel this comes as too little, too
> late to come to this conclusion now.
Too little is a good thing actually!
Andrei
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On 1/24/13 8:41 AM, deadalnix wrote:
[snip]
> Waiting for the shitstorm . . .
Nothing like that at least from me but I can plainly say this proposal has merit but will never get implemented.
Andrei
|
January 24, 2013 Re: @property - take it behind the woodshed and shoot it? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Artur Skawina | On 1/24/13 9:47 AM, Artur Skawina wrote:
> Having ()-less function calls is just insane; if it isn't obvious to you why,
> you just haven't read enough code that (ab)uses them.
You see, this is the kind of argument that I find very damaging to the conversation. It lacks any shred of material evidence, evokes emotion, manipulates the reader's opinion (framing them into incompetent/inexperienced if they disagree), and implies an appeal to authority. Please don't do that anymore.
Thanks,
Andrei
|
Copyright © 1999-2021 by the D Language Foundation