New syntax for comma expression

8 hours ago

Richard (Rikki) Andrew Cattermole

5 hours ago

Paul Backus

5 hours ago

Richard (Rikki) Andrew Cattermole

5 hours ago

Paul Backus

5 hours ago

Richard (Rikki) Andrew Cattermole

During semantic analysis, some code gets lowered to the comma expression.

New'ing anonymous classes are a good example of this.

Right now if hdrgen were to emit it, it looks like this (-vcg-ast to get it):

__anonclass1 foo = Object, LeInterface
{
	void* this;
}
, foo = new __anonclass1;

Proposed grammar:

CommaExpression:
+   "class" ConstructorArgs|opt AnonBaseClassList|opt AggregateBody
+   "__commaExpr" '(' CommaExpression ')'

This would not break code, nor would it affect tuples. No new AST nodes or semantic behaviour. Just hooking an existing language feature to be fully expressable in syntax.

Ideally, this would be able to bypass the DIP process, due to the bug-fixing nature of it.

5 hours ago

Re: New syntax for comma expression

Posted by Richard (Rikki) Andrew Cattermole
in reply to Paul Backus

Permalink

Richard (Rikki) Andrew Cattermole

Posted in reply to Paul Backus

Permalink

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.

Forums