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);

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.

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

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

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

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

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

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

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

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