On Friday, 25 January 2013 at 22:15:51 UTC, Jonathan M Davis wrote:
> They both already work and have do so for ages.
>
> - Jonathan M Davis

Erm? Yes, and thus it was an answer to "you need to mess every function declaration with an annotation"

Philippe Sigaud wrote:

> Such hate...
No hate. Just knowledge out of experience.

> please give us your own code and preferred solution
> to compile-time formatting string checking.
I am not interested in formatting at all. I wrote about the general problem to incorporate expectable many DSL's into one big source base, as D is intended to serve large scale coding.

I am sure that your "stab at it" does not show any intent to approach the general problem.

-manfred

On Friday, January 25, 2013 23:23:50 mist wrote:
> On Friday, 25 January 2013 at 22:15:51 UTC, Jonathan M Davis
> 
> wrote:
> > They both already work and have do so for ages.
> > 
> > - Jonathan M Davis
> 
> Erm? Yes, and thus it was an answer to "you need to mess every function declaration with an annotation"

I know. I was responding to Rob's post which implied that the syntax you gave didn't currently work.

- Jonathan M Davis

On Friday, 25 January 2013 at 22:39:07 UTC, Jonathan M Davis wrote:
> On Friday, January 25, 2013 23:23:50 mist wrote:
>> On Friday, 25 January 2013 at 22:15:51 UTC, Jonathan M Davis
>> 
>> wrote:
>> > They both already work and have do so for ages.
>> > 
>> > - Jonathan M Davis
>> 
>> Erm? Yes, and thus it was an answer to "you need to mess every
>> function declaration with an annotation"
>
> I know. I was responding to Rob's post which implied that the syntax you gave
> didn't currently work.
>
> - Jonathan M Davis

I misread the post by mist, I incorrectly thought that it was a new syntax proposal as I did not know about @property:.

--rt

On Friday, 25 January 2013 at 22:02:06 UTC, Timon Gehr wrote:
> On 01/25/2013 10:44 PM, Zach the Mystic wrote:
>> Here are my two cents:
>>
>> First, about optional parentheses:
>>
>> Optional parentheses = ambiguity.
>> ...
>
> No, you can definitely have ambiguity without optional parentheses.
> Unless that is supposed to be a destructive update. Is your statement ambiguous?

Actually, you're right. I meant: Optional parentheses as a feature leads to ambiguity precisely when they are not used.

>> int foo() { return 4; }
>> auto x = foo; // gives 4 or gives function foo?
>>
>> It seems to me any ambiguity should be an error. However… it only
>> matters when the type system can't provide the missing detail, as above.
>> ...
>
> That is not ambiguous.

But this time *your* comment is ambiguous! If you mean my *statement* is not ambiguous, then yes.

On Saturday, 26 January 2013 at 00:47:38 UTC, Zach the Mystic wrote:
>>
>> That is not ambiguous.
>
> But this time *your* comment is ambiguous! If you mean my *statement* is not ambiguous, then yes.

Actually, that's ambiguous too. My English language statement.

On Friday, January 25, 2013 23:56:24 Rob T wrote:
> I misread the post by mist, I incorrectly thought that it was a new syntax proposal as I did not know about @property:

: works works with any function attribute, as does {}.

- Jonathan M Davis

On Friday, 25 January 2013 at 21:44:28 UTC, Zach the Mystic wrote:
> Here are my two cents:
>
> First, about optional parentheses:
>
> Optional parentheses = ambiguity.
>
> int foo() { return 4; }
> auto x = foo; // gives 4 or gives function foo?\

4, we are talking about D not C.

On Friday, 25 January 2013 at 19:59:59 UTC, Andrei Alexandrescu wrote:
> 1. Syntactic and semantic implications of properties that return callable entities
>

I don't understand why this is a special case in the first place. It should behave just like a variable of the same type, period.

> C has no methods so the syntax "object.method" does not apply to it. In C++, "object.method" is probably the oddest construct in the entire language: it returns a type that exists but has no name, is not expressible syntactically, is not first class (one can't assign "object.method" to a variable), and has only two allowed operations: take address or apply the function call operator "()". Various C++ implementations have extensions that fix this.
>
> Both Walter and I consider these serious lapses in language design. Two of the most accessible elements of syntax do things of considerably low interest and use. I hope I now clarified why I have a dim view of arguments that - implicitly or explicitly - assume the C or C++ behavior in this area is an example to follow on technical grounds. (Clearly, familiarity is a much better argument.)
>

Javascript or C# have solved that issue with C like language nicely. That is why I propose to do the same here (and considering how much C# has been mentioned here, it sound like a serious option). I know that Javascript is a poorly designed language, but on that very specific topic most people agree that was has been done at the time was pure genius.

It removes the weird C/C++ object that have no expressible type, and simplify the situation. Additional benefice is that funName now behave the same in all situation, which is also a simplification of the situation.

> 2. I have tried to add @property appropriately in Phobos, in particular for ranges:
>
> struct SomeRange {
>   @property bool empty();
>   @property ref T front();
>   void popFront();
> }
>
> There's more "@property" to be seen with "save" and "back". Subjectively that just didn't work well for me. It adds clutter to an otherwise simple and straightforward API, and penalizes usage for benefits that I could never reap. I understand how some people are glad to put that in everywhere, and find meaning in requiring parens with popFront and popBack but not the others. Yet for me it was liberating (see 1 above too) I could just write "r.popFront" without the parens and have it do its deed. It is the right semantics for a simple syntax.
>

If you ask me, I think property have been abused in range design. Many ranges properties really shouldn't be properties.

Additionally, this kind of boilerplate can easily be written by automated tools. Java or C# are very verbose, but it is very efficient to write program in them, as the tooling to a great job for you.

As I discussed with you, tooling appears slowly in D because the language itself is unstable, the specification have many quirks, and dmd is not reusable for the job.

We can either make more quirks in order to make our life easier, or less quirks in order for tools to make our life easier. The first one have immediate return on investment, however, it is shortsighted IMO.

> 3. Whatever we do going forward should be _simple_ but not _simplistic_. Right now it's easy to forget that we're all close to the subject. We have it in working memory (at least it's what I think about all the time) and any incremental complexity is an easy cost to absorb intellectually.
>
> But when we need to teach this to newcomers or even approach it again with a "cold cache", any undue complexity will be jarring.
>

Everybody know how a variable behave. This is the most simple and straightforward way for a property to work.

> 4. Whether we like it or not, backward compatibility is an issue. The parens or no parens aspect upon a function call is too ubiquitous to write off as an obscure circumstance. So I don't think the obscurity argument applies.
>
> Granted, there are several ways to approach the compatibility issue, all with their specific tradeoffs. All I'm saying is that careful considerations of compatibility must be integral to whatever we do about this.
>

Whatever solution we choose, it will break stuff. We'd better think of a nice way to handle the transition than a way to not break code.

Think that PHP went from value typed object to reference typed object between 4 and 5. This is a major breakage of a codebase that is much bigger than D's. I was made possible by a great release management.

We'd better acknowledge that our release management sucks, and fix that, than fearing the consequences of it everywhere.

On 1/25/2013 2:14 PM, Jonathan M Davis wrote:
> A property function is fundamentally different from a
> normal function by its very nature, not just by its call syntax.

I would have agreed with you on that for years, simply taking its veracity as an axiom, but lately I am not convinced at all of that assertion. I suspect the differences between a property, field, and method are purely contrivance.

For example, even accessing a global variable isn't straightforward, if you look under the hood. If it's in a DLL or TLS, there may be a function call in there that is non-trivial.