Spot the bug:

template flattenedType(R, uint depth = uint.max)
if (isInputRange!R)
{
	static if (depth > 0)
	{
		static if (!isInputRange!(typeof(R.init.front)))
		{
			alias flattenedType = typeof(R.init.front, depth - 1);
		}
		else
		{
			alias flattenedType = flattenedType!(typeof(R.init.front), depth - 1);
		}
	}
	else
	{
		alias flattenedType = typeof(R.init.front);
	}
}

I'll give you a hint: the bug causes flattenedType!R to always returned uint.

On Tuesday, 15 July 2014 at 08:01:40 UTC, Meta wrote:
> I'll give you a hint: the bug causes flattenedType!R to always returned uint.

What is unexpected about that ?

On Tuesday, 15 July 2014 at 08:20:34 UTC, Martin Krejcirik wrote:
> On Tuesday, 15 July 2014 at 08:01:40 UTC, Meta wrote:
>> I'll give you a hint: the bug causes flattenedType!R to always returned uint.
>
> What is unexpected about that ?

It makes the behaviour of the template that's unexpected. flattenedType!(float[][][][]) returning uint is unexpected. But that's not the problem. The problem is a hard (IMO) to spot bug caused by the comma operator.

Meta:

> Spot the bug:

We can start killing those commas in D 2.067 :-)

Bye,
bearophile

On Tue, Jul 15, 2014 at 08:42:17AM +0000, bearophile via Digitalmars-d wrote:
> Meta:
> 
> >Spot the bug:
> 
> We can start killing those commas in D 2.067 :-)
[...]

Is that the agreed-on schedule? I'd love to see the comma operator go, too, but I don't recall the core devs agreeing on a deprecation date.


T

-- 
There's light at the end of the tunnel. It's the oncoming train.

On Tuesday, 15 July 2014 at 08:01:40 UTC, Meta wrote:
> Spot the bug:
>
> template flattenedType(R, uint depth = uint.max)
> if (isInputRange!R)
> {
> 	static if (depth > 0)
> 	{
> 		static if (!isInputRange!(typeof(R.init.front)))
> 		{
> 			alias flattenedType = typeof(R.init.front, depth - 1);
> 		}
> 		else
> 		{
> 			alias flattenedType = flattenedType!(typeof(R.init.front), depth - 1);
> 		}
> 	}
> 	else
> 	{
> 		alias flattenedType = typeof(R.init.front);
> 	}
> }
>
> I'll give you a hint: the bug causes flattenedType!R to always returned uint.

This isn't a bug! It's a logic mistake.

Why the heck would you have such a line anyways?

alias flattenedType = typeof(R.init.front, depth - 1);

The 2nd "argument" to typeof makes no sense. It shouldn't be on that line at all. Total fail by the programmer.

On Tuesday, 15 July 2014 at 16:01:37 UTC, Frustrated wrote:
> This isn't a bug! It's a logic mistake.
>
> Why the heck would you have such a line anyways?
>
> alias flattenedType = typeof(R.init.front, depth - 1);
>
> The 2nd "argument" to typeof makes no sense. It shouldn't be on that line at all. Total fail by the programmer.

Yes, I wasn't thinking and typed "typeof(R.init.front, depth - 1)" because just a moment before a few lines down I typed "flattenedType!(typeof(R.init.front), depth - 1)". Once the comma operator is deprecated, however, it will be impossible to make this kind of careless mistake.

On 7/15/14, Frustrated via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tuesday, 15 July 2014 at 08:01:40 UTC, Meta wrote:
> The 2nd "argument" to typeof makes no sense. It shouldn't be on
> that line at all. Total fail by the programmer.

Well yeah, real world programmers make mistakes.

On Tuesday, 15 July 2014 at 16:16:19 UTC, Andrej Mitrovic via Digitalmars-d wrote:
> On 7/15/14, Frustrated via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Tuesday, 15 July 2014 at 08:01:40 UTC, Meta wrote:
>> The 2nd "argument" to typeof makes no sense. It shouldn't be on
>> that line at all. Total fail by the programmer.
>
> Well yeah, real world programmers make mistakes.

So, you wanna nerf everything that could produce the wrong behavior? Should be reduce the speed limit to 5mph because cars can kill people?

There is nothing in this example that shows the comma operator is evil. Any programming language as a plethora of similar issues. Should we get rid of || && etc because one might forget to double it?

e.g., if (x | y) when one meant if (x || y)?

It's not the languages fault if you can't pay attention to what you are doing!

The code looks like he copy and pasted the 2nd alias line and forgot to remove the depth part. Again, this speaks nothing about the comma operator but about the programmer.

On Tuesday, 15 July 2014 at 16:45:02 UTC, Jane Doe wrote:
> On Tuesday, 15 July 2014 at 16:16:19 UTC, Andrej Mitrovic via Digitalmars-d wrote:
>> On 7/15/14, Frustrated via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>> On Tuesday, 15 July 2014 at 08:01:40 UTC, Meta wrote:
>>> The 2nd "argument" to typeof makes no sense. It shouldn't be on
>>> that line at all. Total fail by the programmer.
>>
>> Well yeah, real world programmers make mistakes.
>
> So, you wanna nerf everything that could produce the wrong behavior? Should be reduce the speed limit to 5mph because cars can kill people?
>
> There is nothing in this example that shows the comma operator is evil. Any programming language as a plethora of similar issues. Should we get rid of || && etc because one might forget to double it?
>
> e.g., if (x | y) when one meant if (x || y)?
>
> It's not the languages fault if you can't pay attention to what you are doing!
>
> The code looks like he copy and pasted the 2nd alias line and forgot to remove the depth part. Again, this speaks nothing about the comma operator but about the programmer.

The reason for getting rid of it is because it's borderline useless. It causes more accidental bugs than it enables deliberate uses.