On Wednesday, 26 March 2014 at 17:40:36 UTC, Andrei Alexandrescu wrote:
> On 3/26/14, 10:34 AM, monarch_dodra wrote:
>> On Wednesday, 26 March 2014 at 17:27:16 UTC, Andrei Alexandrescu wrote:
>>> Big mistake :o). -- Andrei
>>
>> Yeah, how are we doing on that front? Have any decisions actually been
>> made?
>
> What front?

The "Warn against and then deprecate implicit concatenation of adjacent string literals" issue:
https://d.puremagic.com/issues/show_bug.cgi?id=3827

Yebblies seemed to have something going, since he submitted this:
https://github.com/D-Programming-Language/phobos/pull/1871

I'm not up-to-date on the latest developments in dmd, so I'm asking if any decisions have been made about this?

On 3/26/14, 10:51 AM, monarch_dodra wrote:
> On Wednesday, 26 March 2014 at 17:40:36 UTC, Andrei Alexandrescu wrote:
>> On 3/26/14, 10:34 AM, monarch_dodra wrote:
>>> On Wednesday, 26 March 2014 at 17:27:16 UTC, Andrei Alexandrescu wrote:
>>>> Big mistake :o). -- Andrei
>>>
>>> Yeah, how are we doing on that front? Have any decisions actually been
>>> made?
>>
>> What front?
>
> The "Warn against and then deprecate implicit concatenation of adjacent
> string literals" issue:
> https://d.puremagic.com/issues/show_bug.cgi?id=3827
>
> Yebblies seemed to have something going, since he submitted this:
> https://github.com/D-Programming-Language/phobos/pull/1871
>
> I'm not up-to-date on the latest developments in dmd, so I'm asking if
> any decisions have been made about this?

I personally use the implicit concatenation on occasion and it doesn't trip me, but I wouldn't mind adding a ~.

But in a way that's beside the point. I'd much rather make non-breaking improvements to the language, as there are plenty of opportunities. I feel changing string concatenation right now is just thinking small.


Andrei

Andrei Alexandrescu:

> I personally use the implicit concatenation on occasion and it doesn't trip me, but I wouldn't mind adding a ~.

While it's not a very common bug, it has tripped me few times.

This is where I raised the issue in 2010:
https://d.puremagic.com/issues/show_bug.cgi?id=3827

Walter agreed to remove it:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=121830


> I feel changing string concatenation right now is just thinking small.

Fixing a little design mistake that causes bugs is not stopping all the other people like you from thinking about the more significant issues like concurrency, parallelism, reference scope, synchronized, and so on. Probably 80% of the bugs in Bugzilla are about very small things, like a missing assert, a wrong error message, or even wrong words used in documentation. Fixing those things is useful. Just because a problem is waiting for a fix in Bugzilla for years can't justify to close it down. In Bugzilla there are some other little breaking changes waiting to happen.

There are operator precedence-related problems caused by replacing the implicit concatenation with a ~.


> But in a way that's beside the point. I'd much rather make non-breaking improvements to the language, as there are plenty of opportunities.

I don't agree. It's much better to fix the little breaking changes now, and think about non-breaking improvements later. Because later the breaking changes will become less and less possible.

Bye,
bearophile

On 3/26/14, 11:36 AM, bearophile wrote:
> Fixing a little design mistake that causes bugs is not stopping all the
> other people like you from thinking about the more significant issues
> like concurrency, parallelism, reference scope, synchronized, and so on.

Doesn't seem like it. From where I stand, all these petty debates that last forever take focus away from a small team of core contributors. A dozen people are laying the bricks, whereas everybody else wrings their hands on the side and occasionally point out a spec of dust that's not where they think it should be.

>> But in a way that's beside the point. I'd much rather make
>> non-breaking improvements to the language, as there are plenty of
>> opportunities.
>
> I don't agree. It's much better to fix the little breaking changes now,
> and think about non-breaking improvements later. Because later the
> breaking changes will become less and less possible.

That later is already now.


Andrei

Andrei Alexandrescu:

> I'd much rather make non-breaking improvements to the
> language, as there are plenty of opportunities.

Three improvements I'd like for D:
- A not ugly and handy syntax for tuples;
- Optionally strongly typed array indexes;
- "enum preconditions" or something similar.

The first helps me write functional code without doing contortions. The second is something I miss from Delphi/Ada and helps write medium integrity code with more safety. The third avoids some run-time bugs.

Bye,
bearophile

On Wednesday, 26 March 2014 at 11:08:45 UTC, Andrej Mitrovic wrote:
> On 3/26/14, Kagamin <spam@here.lot> wrote:
>> On Tuesday, 25 March 2014 at 17:58:45 UTC, bearophile wrote:
>>> I think total removal of the comma operator could offer more
>>> readable D code.
>>
>> No, complete removal will make code less readable. Why can't you
>> read commas?
>
> Have you never experienced this bug before?
>
> enum vals = [
>     "afoo01foo01",
>     "bbar02foo02",
>     "cdoo03foo03",
>     "dfoo01foo04",
>     "ebar02foo01",
>     "fdoo03foo02",
>     "gfoo01foo03",
>     "hbar02foo04",
>     "aidoo03foo01"
>     "jfoo01foo02a",
>     "kbar02foo03",
>     "ldoo03foo04",
> ];
>
> This has nothing to do with the comma operator, but what it has to do
> is with readability. The comma is easily misplaced.

I have done that so many times in Python. It's much harder to catch in Python too, due to dynamic typing.

On 3/26/2014 7:44 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> On Tuesday, 25 March 2014 at 19:25:43 UTC, ixid wrote:
>>> I think this should not be done. Note that even though code which is
>>> D could reintroduce commas safely, C code will still exist at that
>>> time, and likely need porting to D. The principle that C code should
>>> either do the same thing, or not compile, would be violated.
>>
>> What would be an example of C code that would compile in a D
>> where the comma operator was used for tuples? Also why is cut and
>> pasting C code to D so important? If it's non-trivial surely
>> people will just use extern C. If it's trivial they can make the
>> minor improvements necessary.
>
> This is valid in both C and C++:
>
>    i, j = 0, 1;
>
> It is equivalent to the following:
>
>    i;
>    j = 0;
>    1;
>

Under the proposal, the "0, 1" would be void, so it wouldn't compile in D. Therefore, the rule about moving C code to D safely is not violated.

On 03/26/2014 05:19 PM, H. S. Teoh wrote:
> 	int x = 1, 5;	// hands up, how many understand what this does?

Nothing. This fails to parse because at that place ',' is expected to be a separator for declarators.

On 03/26/2014 08:49 PM, Andrei Alexandrescu wrote:
>>
>> I don't agree. It's much better to fix the little breaking changes now,
>> and think about non-breaking improvements later. Because later the
>> breaking changes will become less and less possible.
>
> That later is already now.

So how come there exists this thread on breaking the comma operator?

On 3/26/14, 3:13 PM, Timon Gehr wrote:
> On 03/26/2014 08:49 PM, Andrei Alexandrescu wrote:
>>>
>>> I don't agree. It's much better to fix the little breaking changes now,
>>> and think about non-breaking improvements later. Because later the
>>> breaking changes will become less and less possible.
>>
>> That later is already now.
>
> So how come there exists this thread on breaking the comma operator?

Because it's arguably worth it. -- Andrei