January 25, 2013
On 2013-01-24 17:29, Andrei Alexandrescu wrote:

> That means there must be two overloads of f exactly:
>
> T f();
> f(T);

That's somewhat problematic since it won't allow chaining assignments:

auto i = f = 3;

We need to either allow:

T f ();
T f (T);

Or implement some form of rewrite:

f = 3; // calls setter
auto i = f; // calls getter

This is the preferred solution.

-- 
/Jacob Carlborg
January 25, 2013
On Friday, 25 January 2013 at 09:12:47 UTC, Jacob Carlborg wrote:
> On 2013-01-24 17:29, Andrei Alexandrescu wrote:
>
>> That means there must be two overloads of f exactly:
>>
>> T f();
>> f(T);
>
> That's somewhat problematic since it won't allow chaining assignments:
>
> auto i = f = 3;
>
> We need to either allow:
>
> T f ();
> T f (T);
>
> Or implement some form of rewrite:
>
> f = 3; // calls setter
> auto i = f; // calls getter
>
> This is the preferred solution.

Assignation is right associative, so it is equivalent to :
auto i = (f = 3);

The setter is called.
January 25, 2013
On 2013-03-25 04:01, Manfred Nowak <svv1999@hotmail.com> wrote:

> Nick Treleaven wrote:
>
>> write!"%s\n" = someExpression;
>
> Iff at all I prefer `write!someExpression= "%s\n";'
>
> Seriously, checking validity at execution time causes another sort
> of hiccoughs that should not be part of a language intended for
> large scale coding.

From what I can see, Nick's solution allows compile time validity
checking whereas yours does not.

-- 
Simen
January 25, 2013
On 2013-01-24 22:08, Adam Wilson wrote:

> While I don't approve of Mr. Sabalausky's tone or attitude, the crux of
> his argument is logically sound. The problem with @property isn't
> @property, it's D's insistence on optional parens. If paren usage was
> clearly defined then this would be a non-issue. I would like to point
> out that I can't think of another systems/general purpose language that
> has an calling syntax specification as vague and convoluted as D's. C#'s
> is brutally simple. Java's is brutally simple. In C/C++ everything is a
> function or field, so, brutally simple.
>
> Make D's calling syntax simpler, end optional parens!

There are many languages that allow optional parentheses when calling a function. Ruby, CoffeeScript and Groovy to mention a few.

-- 
/Jacob Carlborg
January 25, 2013
On Thursday, 24 January 2013 at 20:52:10 UTC, Walter Bright wrote:
> On 1/24/2013 5:42 AM, Jacob Carlborg wrote:
>> I agree with you but Walter is very afraid of breaking code.
>
> The history of what happens when D code breaks because of language changes is not a happy one.

I don't believe that is true. Remember when 'bit' was removed from the language?
It didn't cause any complaints at all.

This attitude is very harmful. Our real problem is that we're not making promises about what we won't change. When we haven't made such promises, we then become fearful of changing *anything*.
Then we bend over backwards to avoid changing things that actually nobody cares about. This is a recipe for locking bugs into the language forever.

Instead, we should be trying to continuously expand the things we guarantee will continue to work. Ideally we would be precise about the things that are likely to change, and which we don't currently guarantee.
January 25, 2013
On Friday, 25 January 2013 at 09:38:27 UTC, Jacob Carlborg wrote:
> On 2013-01-24 22:08, Adam Wilson wrote:
>
>> While I don't approve of Mr. Sabalausky's tone or attitude, the crux of
>> his argument is logically sound. The problem with @property isn't
>> @property, it's D's insistence on optional parens. If paren usage was
>> clearly defined then this would be a non-issue. I would like to point
>> out that I can't think of another systems/general purpose language that
>> has an calling syntax specification as vague and convoluted as D's. C#'s
>> is brutally simple. Java's is brutally simple. In C/C++ everything is a
>> function or field, so, brutally simple.
>>
>> Make D's calling syntax simpler, end optional parens!
>
> There are many languages that allow optional parentheses when calling a function. Ruby, CoffeeScript and Groovy to mention a few.

From what I see on CofeeScript website, it has a VERY different semantic than D on function.
January 25, 2013
On 01/24/2013 11:32 PM, Adam Wilson wrote:
> On Thu, 24 Jan 2013 14:15:45 -0800, Robert Schadek <realburner@gmx.de> wrote:
>
>> On 01/24/2013 10:56 PM, Adam Wilson wrote:
>>> On Thu, 24 Jan 2013 13:54:09 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> On 1/24/13 4:08 PM, Adam Wilson wrote:
>>>>> On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
>>>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>>>
>>>>>> On 1/24/13 3:45 PM, Nick Sabalausky wrote:
>>>>>>> On Thu, 24 Jan 2013 12:51:32 -0500
>>>>>>> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>>>>>>> No, you merely came up with *some* specific cherry-picked examples that
>>>>>>> sparked *some* debate (with most of the disagreing coming from
>>>>>>> you).
>>>>>>
>>>>>> I simply mentioned three reasons that came to mind.
>>>>>>
>>>>>> Andrei
>>>>>
>>>>> While I don't approve of Mr. Sabalausky's tone or attitude, the crux of
>>>>> his argument is logically sound. The problem with @property isn't
>>>>> @property, it's D's insistence on optional parens. If paren usage was
>>>>> clearly defined then this would be a non-issue. I would like to point
>>>>> out that I can't think of another systems/general purpose language that
>>>>> has an calling syntax specification as vague and convoluted as D's. C#'s
>>>>> is brutally simple. Java's is brutally simple. In C/C++ everything is a
>>>>> function or field, so, brutally simple.
>>>>>
>>>>> Make D's calling syntax simpler, end optional parens!
>>>>
>>>> Simplicity is clearly good, but there's something to be said about those warts in chained calls. The UFCS-enabled idioms clearly bring a strong argument to the table, there's no ignoring it.
>>>>
>>>> Andrei
>>>
>>> Then @property needs to be fixed such that optional parens don't effect it one way or the other. Removing the concept of properties and making functions that look like properties through optional parens is a very poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, and functions do stuff. That statement alone is an excellent argument for clearly delineating which is which... Properties are not functions.
>>>
>>
>> At while you're at it, just get ride of:
>>
>> int[] a.
>> a.length = 10;
>>
>> That this grows the array stills creeps me out.
>>
>> Robert
>
> Well, from a syntax standpoint it's legitimate, and D's dynamic arrays are something I prefer over C#'s less flexible solution. My main problem with using it is that D's GC is absurdly naive. When this seemingly benign action causes your program to freeze for non-trivial fractions of a second for the millionth time, it can be quite despair inducing...
>
Yes, the syntax is legit. It's the semantic that "scares" me. IMHO it feels strange that assigning a variable resizes a array. Something like a.resize(10) would make me feel better.
January 25, 2013
On Thursday, 24 January 2013 at 22:45:52 UTC, Walter Bright wrote:
> Having a release process does not remove the pain of breaking changes that make users miserable because their older code no longer compiles.

Beg my pardon, it is very ignorant position. It assumes user is some kind of stubborn creature that is scared of any spec changes. But it is not really the case. Users are not afraid of compiler release breaking their code - they are afraid of not having a single compiler version that both is stable enough and works for their code. And that it is very different.

It is fine to break code in release if you still provide bug-fixes to some older version that may be recommended for usage until time to fix code base is taken. And this is exactly where good release process shines, it is single most important reason to have it.

To sum up my position:
1) D spec is imperfect
2) Breaking change are inevitable
3) Saying "breaking changes" are bad means hiding the problem
4) It is better to focus on process to minimize breaking changes damage than rant about how bad they are
5) Leaving feature badly designed for years with no hope to change is worse than breaking code.

I'd really like to read your position on _all_ of those statements, because we are running circles here.
January 25, 2013
On Thursday, 24 January 2013 at 21:23:53 UTC, Andrei Alexandrescu wrote:
> ...

Sorry Andrei, with all my due respect, you have a brilliant talent to answer something without actually stating any own position on topic.

Please take a look to my answer to Walter: http://forum.dlang.org/post/lpdegnaygbiijuwddgpf@forum.dlang.org

I'd really like to understand your position too, because arguing about sentences leads nowhere.
January 25, 2013
On Friday, 25 January 2013 at 09:49:29 UTC, Don wrote:
> ...

++

It feels that "breaking code" has become some kind of scary ghost that is just being afraid of instead of some kind of analysis-based approach.

18 19 20 21 22 23 24 25 26 27 28 29 30