On Tuesday, 10 May 2016 at 23:33:13 UTC, mogu wrote:
> On Tuesday, 10 May 2016 at 21:49:10 UTC, Nordlöw wrote:
>> On Tuesday, 10 May 2016 at 21:33:47 UTC, Stefan Koch wrote:
>>> On Tuesday, 10 May 2016 at 21:30:35 UTC, Timon Gehr wrote:
>>>> Kill it.
>>>
>>> I agree.
>>
>> Agreed. Builtin tuple syntax is far more useful.
>
> +1. And personally, match is expected then.

+1. The comma operator should go, especially if it makes tuple syntax possible.

On Tuesday, 10 May 2016 at 12:49:28 UTC, Steven Schveighoffer wrote:
> Note, there was some pretty good examples of (ab)use of the comma operator in one of those: https://github.com/dlang/dmd/pull/3399#issuecomment-38401339

If we had control flow statements as expressions one could rewrite
return a(), b;
as
a(), return b;

and thus wouldn't need the C comma expression semantics.

On Wednesday, 11 May 2016 at 00:32:33 UTC, Mithun Hunsur wrote:
> +1. The comma operator should go, especially if it makes tuple syntax possible.

To clarify a possible misunderstanding: tuples are possible in D3, and macros, and concepts, and parametric polymorphism.

On Wednesday, 11 May 2016 at 09:03:29 UTC, Kagamin wrote:
> On Tuesday, 10 May 2016 at 12:49:28 UTC, Steven Schveighoffer wrote:
>> Note, there was some pretty good examples of (ab)use of the comma operator in one of those: https://github.com/dlang/dmd/pull/3399#issuecomment-38401339
>
> If we had control flow statements as expressions one could rewrite
> return a(), b;
> as
> a(), return b;
>
> and thus wouldn't need the C comma expression semantics.

I haven't found any use for control flow statements as expressions in D (even though I have programmed in Ruby) so far, because the ternary operator covers all my needs.

In this case the intent would be much more clear if you wrote:
a(); return b;

On Wednesday, 11 May 2016 at 09:06:40 UTC, Kagamin wrote:
> On Wednesday, 11 May 2016 at 00:32:33 UTC, Mithun Hunsur wrote:
>> +1. The comma operator should go, especially if it makes tuple syntax possible.
>
> To clarify a possible misunderstanding: tuples are possible in D3, and macros, and concepts, and parametric polymorphism.

By "parametric polymorphism" do you mean multiple dispatch/multimethods? This can sort of be emulated in library. Think something like Variant.visit that takes multiple variants as parameters. So building it into the language doesn't seem like it should be a priority.

Concepts are the wrong solution to the problem and probably would never happen. The design of std.experimental.allocator proves that they are inadequate for solving even simple problems like static polymorphism.

Macros... well I think a solution like Jonathan Blow's Jai CTFE inside the compiler would be much more powerful and easy to integrate into the language. But it will require heavy refactoring of DMDFE, but this is a good idea regardless.

Tuples and some sort of pattern matching for values (like is() is for types) are a total must have. Though if we get rid of the comma operator, it may happen earlier than D3. From watching D's evolution from last 2-3 years I think that there may never be a D3. Just cool new features that every other release, and graceful deprecation of old misfeatures.

On 11.05.2016 11:39, ZombineDev wrote:
>
> By "parametric polymorphism" do you mean multiple dispatch/multimethods?

It's a type system feature. It allows one uniform implementation to work on different types without a loss of type information (i.e., by using a variant, or up-casting to a less specific type). Templates are often used to solve similar problems, but they give you different implementations if you ask for different types, which does not work for delegates and function pointers (including virtual functions), if you need to recurse with changing type arguments, etc.

'inout' is a very restricted form of this.

I don't think this is on the same level as tuple support though.

On 10/5/2016 22:16, deadalnix wrote:
> On Tuesday, 10 May 2016 at 10:09:40 UTC, Andrei Alexandrescu wrote:
>> On 5/10/16 12:52 PM, Mathias Lang wrote:
>>> So, following DConf2016, I raised a P.R. to deprecate usage of the comma
>>> expressions, except within `for` loops increment [5].
>>
>> The agreed-upon ideea was to allow uses that don't use the result
>> (including for loops). No? -- Andrei
>
> Let's just make it of void type, there was plan to recycle the syntax
> maybe, but whatever we do in the future, this is the sensible first step.

Acutally, we can do two-birds-one-stone: instead of making it void, make it a value tuple!

If the result of the comma operator gets used in a bug prone matter it would cause a compile error! How is that for "Yeah, sorry, we broke your code, but look what you got in return!"

Win-win!

On 2016-05-11 11:39, ZombineDev wrote:

> Macros... well I think a solution like Jonathan Blow's Jai CTFE inside
> the compiler would be much more powerful and easy to integrate into the
> language. But it will require heavy refactoring of DMDFE, but this is a
> good idea regardless.

Macros are not hard to implement, at least not the kinds that Scala is using.

> Tuples and some sort of pattern matching for values (like is() is for
> types) are a total must have. Though if we get rid of the comma
> operator, it may happen earlier than D3. From watching D's evolution
> from last 2-3 years I think that there may never be a D3. Just cool new
> features that every other release, and graceful deprecation of old
> misfeatures.

Pattern matching can be implemented as a library. That syntax will not be very nice though. But perhaps with macros ;)

-- 
/Jacob Carlborg

On Wednesday, 11 May 2016 at 10:50:47 UTC, Lionello Lunesu wrote:
> On 10/5/2016 22:16, deadalnix wrote:
>> On Tuesday, 10 May 2016 at 10:09:40 UTC, Andrei Alexandrescu wrote:
>>> On 5/10/16 12:52 PM, Mathias Lang wrote:
>>>> So, following DConf2016, I raised a P.R. to deprecate usage of the comma
>>>> expressions, except within `for` loops increment [5].
>>>
>>> The agreed-upon ideea was to allow uses that don't use the result
>>> (including for loops). No? -- Andrei
>>
>> Let's just make it of void type, there was plan to recycle the syntax
>> maybe, but whatever we do in the future, this is the sensible first step.
>
> Acutally, we can do two-birds-one-stone: instead of making it void, make it a value tuple!
>

No. You can't change semantic to something that'll still work under the feet of the user. If this syntax is to be recycled to tuple, the value needs to be void for a while as to shake out uses.

It is safe to go from void to something else, it isn't not to go from something to something else.

On Tuesday, 10 May 2016 at 09:52:07 UTC, Mathias Lang wrote:

>
> Do you like comma expressions, ...

I am a student.
In C, one scenario where I like comma is this.


int x;
while( scanf("%d", &x),  x!= 0) // until user input 0.
{
   //do something with x
}

Without the comma operator, I would have to repeat the scanf statement.
int x;
scanf("%d", &x);
while(x != 0)
{
   //do something with x
   scanf("%d", &x);
}

Does anybody think that this is a useful case of comma operator?