January 24, 2013
On Thursday, 24 January 2013 at 15:02:02 UTC, deadalnix wrote:
> On Thursday, 24 January 2013 at 14:53:49 UTC, Maxim Fomin wrote:
>> On Thursday, 24 January 2013 at 14:25:18 UTC, 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.
>>>
>>
>> C has strings as a concept and C++ as a library solution. Which strings are better: C, C++ or D?
>
> D string string is not builtin. string is merely a thing in D.
>
> D have builtin slices, which is a generic feature that is used with whatever you want.

Perhaps a bad example but I disagree that any feature that can be implemented as a library, should not be introduced as a language feature. Some features needed to be embedded into language because as a library features they would be very ugly.
January 24, 2013
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).
January 24, 2013
On Thursday, 24 January 2013 at 15:32:36 UTC, Maxim Fomin wrote:
> Perhaps a bad example but I disagree that any feature that can be implemented as a library, should not be introduced as a language feature. Some features needed to be embedded into language because as a library features they would be very ugly.

Yes, that is true. But in our case, the library solution isn't ugly.
January 24, 2013
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.

Andrei


January 24, 2013
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.

Andrei
January 24, 2013
On 1/24/13 4:28 AM, monarch_dodra wrote:
> We actually have one, which I think I agree with:
> http://wiki.dlang.org/DIP21

Walter convinced me last night that eliminating @property is more sensible.

Andrei

January 24, 2013
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.
January 24, 2013
On Thursday, 24 January 2013 at 16:30:45 UTC, Andrei Alexandrescu wrote:
> On 1/24/13 4:28 AM, monarch_dodra wrote:
>> We actually have one, which I think I agree with:
>> http://wiki.dlang.org/DIP21
>
> Walter convinced me last night that eliminating @property is more sensible.

He hasn't even *tried* to address the arguments which led to the introduction of @property here, though.

I don't like @property myself, and even less the current broken implementation, but just saying »meh, we don't need it anyway« without even reviewing the reasons that led to its introduction is the worst possible way of handling the situation. And if this has already been done, why not summarize the rationale for removing it anyway here?

Otherwise, everybody has to dig through numerous threads in the archives in order to even *join* the discussion. I'm sure many people just shouting "+1" here have not considered the behavior in the various special cases involved.

In any case, I'm looking forward to seeing these points addressed in a DIP on the topic.

David
January 24, 2013
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.

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


Andrei
January 24, 2013
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
1 2 3 4 5 6 7 8 9 10 11 12 13