On 21/11/2024 2:59 PM, Paul Backus wrote:
> On Wednesday, 20 November 2024 at 23:11:37 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> During semantic analysis, some code gets lowered to the comma expression.
>>
>> [...]
>>
>> Proposed grammar:
>>
>> ```diff
>> CommaExpression:
>> +   "class" ConstructorArgs|opt AnonBaseClassList|opt AggregateBody
>> +   "__commaExpr" '(' CommaExpression ')'
>> ```
> 
> As a general rule, I don't think we should be adding new syntax to D because it's easier for the compiler to generate than the existing syntax.

This is not an ease of use situation.

There is nothing for the lowering to map to in the syntax.

I.e.

```d
void main() {
    bool b;
	auto v = b ? (
        new class LeClass, LeInterface {}
        ) : (
        new class LeClass, LeInterface {}
        );
}

```

```
void main()
{
	bool b = false;
	LeClass v = b ? LeClass, LeInterface
	{
		void* this;
		@system this()
		{
			super.this();
			return this;
		}
	}
	 , new __anonclass2 : (LeClass, LeInterface
	{
		void* this;
		@system this()
		{
			super.this();
			return this;
		}
	}
	 , new __anonclass3);
	return 0;
}
```

Can't go and mess around with statement insertion for something like this. Of course feel free to try ;)

> If there's something in D's semantics that the existing syntax *can't express*, then there's a discussion to be had. But I don't think this qualifies.

Yup, there is plenty unfortunately.

https://github.com/search?q=repo%3Adlang%2Fdmd+%22new+CommaExp%22&type=code

On Thursday, 21 November 2024 at 02:09:14 UTC, Richard (Rikki) Andrew Cattermole wrote:
>
> On 21/11/2024 2:59 PM, Paul Backus wrote:
>> As a general rule, I don't think we should be adding new syntax to D because it's easier for the compiler to generate than the existing syntax.
>
> This is not an ease of use situation.
>
> There is nothing for the lowering to map to in the syntax.

Why does the lowering have to map to anything? It's an implementation detail of the compiler.

On 21/11/2024 3:26 PM, Paul Backus wrote:
> On Thursday, 21 November 2024 at 02:09:14 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>
>> On 21/11/2024 2:59 PM, Paul Backus wrote:
>>> As a general rule, I don't think we should be adding new syntax to D because it's easier for the compiler to generate than the existing syntax.
>>
>> This is not an ease of use situation.
>>
>> There is nothing for the lowering to map to in the syntax.
> 
> Why does the lowering have to map to anything? It's an implementation detail of the compiler.

It's not an implementation detail of the compiler.

The comma expression is in the language. But because of tuples its on the way out and so it doesn't support everything that it needs to.

Regardless the .di generator is broken for D code. That means errors are not emitting correct code either. This affects a lot more than just a couple of switches.

A simple parser change that won't break code and which has the chance to fix some hard problems should be an easy win.

If you think this can be fixed another way, please prove me wrong. I'd love for the .di generator to be functional regardless of who or what approach is taken to achieve it.

On 22/11/2024 6:56 AM, Nick Treleaven wrote:
> Maybe:
> 
> |(){ class __anonclass1 : BaseClassList { void* this; } return new __anonclass1 args; }() |
> 
> Could that work correctly with the context pointer?

Context pointer is irrelevant, it won't work.

```d
    bool b;
	auto v = b ? (
        new class LeClass, LeInterface {}
        ) : (
        new class LeClass, LeInterface {}
        );
```

```
	bool b = false;
	LeClass v = b ? LeClass, LeInterface
	{
		void* this;
		@system this()
		{
			super.this();
			return this;
		}
	}
	 , new __anonclass2 : (LeClass, LeInterface
	{
		void* this;
		@system this()
		{
			super.this();
			return this;
		}
	}
	 , new __anonclass3);
```

The joys of expressions being a tree.

> Otherwise to generally fix it, there would need to be a way of declaring inline types in an expression. (We also might want inline template syntax).

The only type we need to declare inline is classes, as far as I'm aware, which I did add to the grammar (but may have forgotten the class name identifier *sigh*).