On 01/24/2013 07:16 PM, Nick Sabalausky wrote:
> On Thu, 24 Jan 2013 11:25:38 -0500
> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 1/24/13 3:20 AM, Jacob Carlborg wrote:
>>> On 2013-01-24 03:02, Nick Sabalausky wrote:
>>>
>>>> foo.bar() // Perform action
>>>> foo.bar // Access data
>>>
>>> Who says it has to be like this.
>>
>> Agreed. It's an implied, unstated assumption - the most dangerous
>> kind.
>>
>
> It's dangerous to *break*, not to follow.
>

It's somewhat dangerous to assume but not to follow at the same time. No significantly stronger statement can be made, which is why this is a matter of taste.

On 01/24/2013 07:12 PM, Andrei Alexandrescu wrote:
> On 1/24/13 11:32 AM, deadalnix wrote:
>> On Thursday, 24 January 2013 at 16:27:02 UTC, Andrei Alexandrescu wrote:
>>> On 1/24/13 3:38 AM, Tommi wrote:
>>>> I've always secretly hated the ambiguity in D's syntax. E.g:
>>>>
>>>> foo.bar
>>>>
>>>> What could foo and bar be? D has many more answers than C++:
>>>>
>>>> D C++
>>>> foo bar foo bar
>>>> Module/Namespace x x
>>>> Type x x
>>>> Variable x x x x
>>>> Method x
>>>> Free function x x
>>>
>>> Nah, C++ has also namespace, inner classes and function-local
>>> classes... lookup and resolution are actually more complicated than D.
>>>
>>
>> No. C++ has no forward references, no UFCS, and no way to introduce new
>> symbols during semantic analysis.
>>
>> C++ is an horrible beast, but on the identifier side, D is far worse.
>
> Well if D is worse, should we give up on forward references, UFCS, or
> mixins?
>
> Andrei

Also, static if and 'is' expressions.
No, but we must specify and implement a sophisticated evaluation model of compile-time code evaluation, introspection, and generation constructs. DMD gets it wrong. Semantics of code, or whether it is accepted may depend on the order modules are passed on the command line.
I'll release what I have got so far later in spring.

On 2013-01-24 19:16, Nick Sabalausky wrote:

> It's dangerous to *break*, not to follow.

Follow what? There are several languages that don't care if you use parentheses when calling a method.

-- 
/Jacob Carlborg

On Thursday, 24 January 2013 at 18:01:30 UTC, Andrei Alexandrescu wrote:
> On 1/24/13 9:25 AM, deadalnix wrote:
>> On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:
>>> We need a good DIP on this. UFCS has destroyed all arguments in favor
>>> of requiring parens. There is no question we must do this. Anyone
>>> inclined toward writing a detailed DIP?
>>>
>>
>> Let me strongly disagree. Language feature should never be introduced
>> where library solution is possible.
>
> Absolutes are difficult positions in language design.
>

This is why I used should and not must.

>> And library solution is possible. And opDispatch makes it possible.
>
> Problem is, a lot of code would need to add opDispatch. I don't think that's good language design.
>

Not at all, you can provide one via UFCS.

On 2013-01-24 17:27, Andrei Alexandrescu wrote:

> Nah, C++ has also namespace, inner classes and function-local classes...
> lookup and resolution are actually more complicated than D.

A namespace in C++ would be using a double colon, not a dot.

-- 
/Jacob Carlborg

On Thursday, 24 January 2013 at 18:12:22 UTC, Andrei Alexandrescu wrote:
> Well if D is worse, should we give up on forward references, UFCS, or mixins?
>

No, I don't think we should drop them. I'm just mentioning that identifier resolution in harder in D than in C++ , but never said that identifier resolution should be easy.

On Thursday, 24 January 2013 at 19:36:35 UTC, Dmitry Olshansky wrote:
> The same argument was brought about overloading  operators, about overloading functions, etc. In other words the argument is WYSIWYG, but humans inherently think in overloaded notions and take obvious shortcuts
> just about everywhere.
>

That is not because it is ambiguous, where . overload behavior for pointer isn't.

Such behavior would be like if pointer dereferenced automagically and you add to put & everywhere to not dereference them. That would be an horrible behavior, as well as calling function automatically is an horrible behavior.

So we want to avoid () for convenience. I have noting against convenience, but here it is plain wrong :
 - We have 2 syntax to do the same thing.
 - If the return value is callable, it is unclear what is done.
 - We need something to NOT call the function, as it is called magically. Let's introduce &funName syntax and mess up with another feature.
 - It is now unclear when we take the return address or the address of the function.
 - It is also not clear how to pass a function as parameter (we have seen the case recently).
 - Depending on the callable, () and & have different behaviors, which is error prone, harder to learn for newcomer, harder for generic code, and exactly what everybody hate about C++ .

I have nothing against convenience, and like very much the pointer + dot behavior. I actuelly proposed something similar with functions : function.identifier can call the function without (), which is the equivalent of the pointer thing in term of convenience. Going further inherently mess up with other features of the language.

Am Fri, 25 Jan 2013 00:11:24 +0100
schrieb Timon Gehr <timon.gehr@gmx.ch>:

> On 01/24/2013 04:45 PM, Johannes Pfau wrote:
> > Am Thu, 24 Jan 2013 09:20:44 +0100
> > schrieb Jacob Carlborg <doob@me.com>:
> >
> >> On 2013-01-24 03:02, Nick Sabalausky wrote:
> >>
> >>> foo.bar() // Perform action
> >>> foo.bar   // Access data
> >>
> >> Who says it has to be like this.
> >>
> >
> > .NET guidelines since .NET 1.1 for example:
> >
> > "In general, methods represent actions and properties represent
> > data." (http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).
> >
> 
> This is not C#.

I think I misunderstood the question. If the question was whether the parenthesis mark an action as opposed to data access, then my statement is of course void. (But it's a tradition from C that () mark function calls).

I thought he meant properties should be used for data access. This is almost by definition: Java used setX /getX, C# formalized that into properties, D took properties from C#. Properties where always used for data access, if you don't use properties for data access but for other things the whole concept doesn't make sense. So in that case "this is C#".

Properties are polymorphic fields, nothing more nothing less. The D implementation is horrible though as you can't do  stuff like x.field++. However, how would you implement this without properties and fields:

x.value++; //Field or property
x.setValue(x.getValue()++); //How ugly...
x.setValue(x.getValue++); //Really ugly (optional parentheses func call)

You can't allow these rewrites for normal functions, it'll be a disaster and this is why we need properties. And it's also the reason why properties are data: they're fields and fields are data.

On Thursday, 24 January 2013 at 23:11:25 UTC, Timon Gehr wrote:
> This is not C#.
Ye, exactly. Contrary to C#, our properties suck.

On 01/25/2013 05:56 PM, Johannes Pfau wrote:
> Am Fri, 25 Jan 2013 00:11:24 +0100
> schrieb Timon Gehr <timon.gehr@gmx.ch>:
>
>> On 01/24/2013 04:45 PM, Johannes Pfau wrote:
>>> Am Thu, 24 Jan 2013 09:20:44 +0100
>>> schrieb Jacob Carlborg <doob@me.com>:
>>>
>>>> On 2013-01-24 03:02, Nick Sabalausky wrote:
>>>>
>>>>> foo.bar() // Perform action
>>>>> foo.bar   // Access data
>>>>
>>>> Who says it has to be like this.
>>>>
>>>
>>> .NET guidelines since .NET 1.1 for example:
>>>
>>> "In general, methods represent actions and properties represent
>>> data." (http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).
>>>
>>
>> This is not C#.
>
> I think I misunderstood the question. If the question was whether the
> parenthesis mark an action as opposed to data access, then my
> statement is of course void. (But it's a tradition from C that () mark
> function calls).
>
> I thought he meant properties should be used for data access. This is
> almost by definition: Java used setX /getX, C# formalized that into
> properties, D took properties from C#. Properties where always used
> for data access, if you don't use properties for data access but for
> other things the whole concept doesn't make sense. So in that case
> "this is C#".
> ...

I think he meant both. =)