www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Another example of how AI is bad, bug fix for 20875

reply user1234 <user1234 12.de> writes:
see https://github.com/dlang/dmd/issues/20875

```d
struct S
{
     auto front() {}
}

void test()
{
     S res;
     ulong x;
     typeof(res.front)(x);
}
```

the problem is not about arguments. The problem is that the 
sub-expression is not callable. I.E the error message shoud be 
the same as when you unfortunatetly, completly exhausted after a 
12 hours shift, write

```d
void main()
{
     alias FT = void(int);
     FT(0);
}
```

the problem is that the coder wrote a call on a type. If that 
type implements a static opCall then "allrighty" otherwise it's 
not ok to output


 expected 0 arguments, not 1 for non-variadic fun...


It's a bad fix.
Apr 07
parent reply Dennis <dkorpel gmail.com> writes:
On Tuesday, 7 April 2026 at 12:41:59 UTC, user1234 wrote:

 the problem is not about arguments. The problem is that the 
 sub-expression is not callable. I.E the error message shoud be 
 the same as when you unfortunatetly, completly exhausted after 
 a 12 hours shift, write

 ```d
 void main()
 {
     alias FT = void(int);
     FT(0);
 }
 ```


The compiler analyses expressions depth first. It checks 
arguments before checking whether the expression is callable. If 
you change `FT(0)` into `FT("")`, it reports "Error: cannot 
implicitly convert expression `""` of type `string` to `int`" 
which hides the "type `void(int)` is not an expression" error. 
This has always been the case.

Conversely, once you fix the argument list in the test case of 
20875 you will get the "is not an expression" error. Also note 
that calling a type is not necessarily an error, it's fine when 
you don't actually need the value. For example:

```D
alias T = typeof(typeof(res.front)());
```

If you think the "is not an expression" should have priority over 
the argument list error, that's a valid enhancement request, but 
it would be harder to implement (goes against the natural bottom 
up analysis order of the compiler) and would be a separate 
change. The bugfix simply follows existing architectural choices 
of dmd.

I don't appreciate the rabble rousing on the forum by the way. I 
would have preferred a review comment on GitHub, or a new issue 
asking to improve the error message. I like working on open 
source, but it can be stressful for me when I feel like there's a 
large group of strangers watching me, eager to point out every 
way I'm doing things wrong.
Apr 07
next sibling parent reply user1234 <user1234 12.de> writes:
On Tuesday, 7 April 2026 at 14:06:58 UTC, Dennis wrote:

 On Tuesday, 7 April 2026 at 12:41:59 UTC, user1234 wrote:

 [...]


 The compiler analyses expressions depth first. It checks 
 arguments before checking whether the expression is callable. 
 If you change `FT(0)` into `FT("")`, it reports "Error: cannot 
 implicitly convert expression `""` of type `string` to `int`" 
 which hides the "type `void(int)` is not an expression" error. 
 This has always been the case.

 [...]


Look, I' have nothing against you Mr Dennis. It's a whole chain 
of errors: bad PR, poor review, merged too early.
Apr 07
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Tuesday, 7 April 2026 at 14:40:50 UTC, user1234 wrote:

 It's a whole chain of errors: bad PR, poor review, merged too 
 early.


The PR fixes a regression introduced in 2.103.1 and restores the 
old 2.102.2 behavior. For what the PR intends to do, how is it 
'bad'? Did you read my explanation?
Apr 07
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 4/7/26 16:52, Dennis wrote:

 On Tuesday, 7 April 2026 at 14:40:50 UTC, user1234 wrote:

 It's a whole chain of errors: bad PR, poor review, merged too early.


 
 The PR fixes a regression introduced in 2.103.1 and restores the old 
 2.102.2 behavior. For what the PR intends to do, how is it 'bad'? Did 
 you read my explanation?


The reason why you are getting this reaction is that you credited an LLM 
as a co-author on your commit.
Apr 07
parent reply user1234 <user1234 12.de> writes:
On Tuesday, 7 April 2026 at 15:25:42 UTC, Timon Gehr wrote:

 On 4/7/26 16:52, Dennis wrote:

 On Tuesday, 7 April 2026 at 14:40:50 UTC, user1234 wrote:

 It's a whole chain of errors: bad PR, poor review, merged too 
 early.


 
 The PR fixes a regression introduced in 2.103.1 and restores 
 the old 2.102.2 behavior. For what the PR intends to do, how 
 is it 'bad'? Did you read my explanation?


 The reason why you are getting this reaction is that you 
 credited an LLM as a co-author on your commit.


Yes. And this will happen again.
Apr 07
parent Dennis <dkorpel gmail.com> writes:
On Tuesday, 7 April 2026 at 16:11:26 UTC, user1234 wrote:

 Yes. And this will happen again.


That's all you have to say after being called out? If you stand 
by your action of randomly attacking contributors with false 
technical claims, your account can get banned and your posts 
deleted.
Apr 07
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 4/7/26 16:40, user1234 wrote:

 
 Look, I' have nothing against you Mr Dennis. It's a whole chain of 
 errors: bad PR, poor review, merged too early.


Look, this was the previous behavior:

```d
$ dmd test
Error: unknown, please file report at 
https://github.com/dlang/dmd/issues/new
```

If that is now turned into an error message that includes an 
interpretable location, then that is a good PR and should be merged.

I understand that you are motivated by an anti-AI activist stance, but 
at least stay honest about the facts and don't make up nonsensical 
technical criticisms. Otherwise all you are making clear is that humans 
are also prone to hallucinating.
Apr 07
parent reply Dennis <dkorpel gmail.com> writes:
On Tuesday, 7 April 2026 at 15:23:47 UTC, Timon Gehr wrote:

 I understand that you are motivated by an anti-AI activist 
 stance, but at least stay honest about the facts and don't make 
 up nonsensical technical criticisms. Otherwise all you are 
 making clear is that humans are also prone to hallucinating.


Lol, that made my day and restored my mood. Thanks for that. :)
Apr 07
parent Indraj Gandham <newsgroups indraj.net> writes:
 DMD is deliberately licensed as permissively as possible. It would be public
domain but the belief is IIRC that that's not recognized in all countries,
while the Boost license has been tested in court. Whether that's true is up to
lawyers. Any way, I don't add that line for copyright, it's just there for
transparency, and from what I gathered that co-author line is the standard way
to disclose which model has been used. I'm open to alternatives.


Please note that I am not making any claims about licensing issues.

I am merely suggesting that the "Co-Authored-By" field was probably 
intended for another purpose. However, if this is the standard way it's 
done, then so be it.


 keep on topic please


The topic is borderline invalid in itself. You should comment on the 
PR/issue, not here.
Apr 07
prev sibling next sibling parent reply Indraj Gandham <newsgroups indraj.net> writes:
 The reason why you are getting this reaction is that you credited an LLM as a
co-author on your commit. 


The commit has the following text:

Co-Authored-By: Claude Sonnet 4.6 <noreply anthropic.com>

The US Copyright Office generally considers the output of LLMs to be 
ineligible for copyright protection; one can therefore make the argument 
that an LLM should not be considered a co-author and that this type of 
formal acknowledgement may not be a good idea.

However, it is probably not a big deal.


 I don't appreciate the rabble rousing on the forum by the way. I would have
preferred a review comment on GitHub, or a new issue asking to improve the
error message. I like working on open source, but it can be stressful for me
when I feel like there's a large group of strangers watching me, eager to point
out every way I'm doing things wrong.


There are many more people who do appreciate the time and effort you, 
DLF and others put in. If someone doesn't like something, they are free 
to make their own contributions instead of complaining in a manner that 
is both inappropriate and counterproductive.

Indraj
Apr 07
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Tuesday, 7 April 2026 at 17:34:03 UTC, Indraj Gandham wrote:

 The commit has the following text:

 Co-Authored-By: Claude Sonnet 4.6 <noreply anthropic.com>

 The US Copyright Office generally considers the output of LLMs 
 to be ineligible for copyright protection; one can therefore 
 make the argument that an LLM should not be considered a 
 co-author and that this type of formal acknowledgement may not 
 be a good idea.


DMD is deliberately licensed as permissively as possible. It 
[would be public 
domain](https://forum.dlang.org/post/53AAF314.5090208 digitalmars.com) but the
belief is IIRC that that's not recognized in all countries, while the Boost
license has been tested in court. Whether that's true is up to lawyers. Any
way, I don't add that line for copyright, it's just there for transparency, and
from what I gathered that co-author line is the standard way to disclose which
model has been used. I'm open to alternatives.


 There are many more people who do appreciate the time and 
 effort you, DLF and others put in.


I also appreciate most feedback, but unfortunately negative 
comments always hit so much harder psychologically - even when I 
agree with them!


 If someone doesn't like something, they are free to make their 
 own contributions instead of complaining in a manner that is 
 both inappropriate and counterproductive.


I sometimes gently ask someone to write pull requests instead of 
rants, it usually doesn't go over well 😬
Apr 07
next sibling parent user1234 <user1234 12.de> writes:
On Tuesday, 7 April 2026 at 18:40:41 UTC, Dennis wrote:

 [...]
 I sometimes gently ask someone to write pull requests instead 
 of rants, it usually doesn't go over well 😬


keep on topic please
Apr 07
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Tuesday, 7 April 2026 at 18:40:41 UTC, Dennis wrote:


 I sometimes gently ask someone to write pull requests instead 
 of rants, it usually doesn't go over well 😬


I firmly believe people who work on anything serious, D related, 
should not participate in forum discussions. That will only lead 
to disappointment(s). If someone does not like a PR, or how it is 
implemented, is free to propose a better fix IN THE PR THREAD, 
not on this forum, or submit _own_, better PR that fixes the 
issue.
Apr 07
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2026 11:40 AM, Dennis wrote:

 DMD is deliberately licensed as permissively as possible. It [would be public 
 domain](https://forum.dlang.org/post/53AAF314.5090208 digitalmars.com) but the 
 belief is IIRC that that's not recognized in all countries, while the Boost 
 license has been tested in court. Whether that's true is up to lawyers. Any
way, 
 I don't add that line for copyright, it's just there for transparency, and
from 
 what I gathered that co-author line is the standard way to disclose which
model 
 has been used. I'm open to alternatives.


That makes perfect sense to me.


 There are many more people who do appreciate the time and effort you, DLF and 
 others put in.


 
 I also appreciate most feedback, but unfortunately negative comments always
hit 
 so much harder psychologically - even when I agree with them!


I don't think anyone is immune to those feelings. On the other hand, I've been 
criticized so much it doesn't bother me anymore.

BTW, Dennis, I very much appreciate your contributions! You've been an enormous 
help.
Apr 07
parent lurker <lurker dlang.com> writes:
On Tuesday, 7 April 2026 at 22:52:09 UTC, Walter Bright wrote:

 ...
 I don't think anyone is immune to those feelings. On the other 
 hand, I've been criticized so much it doesn't bother me anymore.

 BTW, Dennis, I very much appreciate your contributions! You've 
 been an enormous help.


Dennis please listen to Walter, ironically after all his work he 
sometimes end up being a punch bag for others but somewhat he use 
to maintain his cool. =)

You're one of the most consistent maintainers in this group. 
Don't listen or bother with the forums too much, you are doing a 
great/hard work.
Apr 07
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2026 10:34 AM, Indraj Gandham wrote:

 The US Copyright Office generally considers the output of LLMs to be
ineligible 
 for copyright protection; one can therefore make the argument that an LLM
should 
 not be considered a co-author and that this type of formal acknowledgement may 
 not be a good idea.


If a submission is all or partially LLM generated code, it's reasonable to say 
so. It can influence how it is reviewed. It will also dilute any claims of 
copyright over it.
Apr 07
parent reply Indraj Gandham <newsgroups indraj.net> writes:
Apologies, I should have been more clear. I meant to refer only to the use of
"Co-Authored-By". I did not intend to suggest that it is acceptable not to
disclose LLM use.

However, I would point out that this field alone does not necessarily provide
enough information to know how the author used the LLM or what proportion of a
submission was generated by an LLM.

I also don't think that it's a given that disclosing the use of LLMs would
dilute any copyright risks; on the contrary I think it might make it worse. It
has been shown that LLMs can reproduce copyrighted works and I don't believe
that a court would invalidate any copyright claim arising from the use of such
output. Even reproducing the structure and other "non-literal" elements of
copyrighted programs could potentially result in penalties. This was
established during the course of Computer Associates Inc. v Altai Inc. in 1992
even though it was determined that no infringement had occurred in that
specific case.

To what extent this is enforceable for LLM output is up for debate, since
neither the user nor the copyright holder may be aware of the infringement.
Nevertheless, relying on a blanket exemption incurs some risk, even if it is
difficult to quantify.
Apr 07
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
How copyright fits in with LLM is an evolving thing. It's just best that we are 
up front about it. Someone shouldn't write "this is original code I wrote" and 
then it turns out to be substantially similar to someone else's code slurped up 
by an LLM. One of the great things about git is if a PR is accused of copyright 
infringement, we will know exactly which lines of code to remove/replace.

Git has solved a pernicious problem I've had now and then - being accused of 
copyright violation. I keep good records and was able to defeat all of them.
But 
with git it's not even an issue - there's the provenance of every line of code, 
all time and date stamped and who contributed it, and it's on github's backup
tapes.
Apr 07
prev sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 8 April 2026 at 00:46:34 UTC, Indraj Gandham wrote:

 Apologies, I should have been more clear. I meant to refer only 
 to the use of "Co-Authored-By". I did not intend to suggest 
 that it is acceptable not to disclose LLM use.


Some possibly-missing context:

Claude Code's system prompt instructs models to include the 
Co-Authored-By line when creating Git commits. It's standard 
behavior, not something Dennis went out of his way to add; in 
fact, _not_ adding it - or crediting the LLM any other way - 
would have been the non-standard behavior here.

In my personal opinion, the application of the Co-Authored-By 
mechanism is perfectly suited for its case. It integrates well 
with GitHub's UI, and shows which commits were created with LLM 
assistance at a glance (e.g. even in commit lists which don't 
show the full commit message).

Objecting to the use of Co-Authored-By in this way is, at this 
point, objecting to the use of a widespread, established 
practice, and therefore IMO unproductive.
Apr 08
prev sibling next sibling parent Lance Bachmeier <no spam.net> writes:
On Tuesday, 7 April 2026 at 14:06:58 UTC, Dennis wrote:


 I don't appreciate the rabble rousing on the forum by the way. 
 I would have preferred a review comment on GitHub, or a new 
 issue asking to improve the error message. I like working on 
 open source, but it can be stressful for me when I feel like 
 there's a large group of strangers watching me, eager to point 
 out every way I'm doing things wrong.


I don't think it makes sense to bring this up in the forum. The 
GH thread is the appropriate place to discuss a PR. On the other 
hand, "I feel like there's a large group of strangers watching 
me, eager to point out every way I'm doing things wrong" is 
accurate for any contribution one might make. I congratulate you 
and anyone else willing to put up with it, but it's certainly not 
how I'd choose to spend my free time.
Apr 07
prev sibling parent libxmoc <libxmoc gmail.com> writes:
On Tuesday, 7 April 2026 at 14:06:58 UTC, Dennis wrote:

 On Tuesday, 7 April 2026 at 12:41:59 UTC, user1234 wrote:

 the problem is not about arguments. The problem is that the 
 sub-expression is not callable. I.E the error message shoud be 
 the same as when you unfortunatetly, completly exhausted after 
 a 12 hours shift, write

 ```d
 void main()
 {
     alias FT = void(int);
     FT(0);
 }
 ```


 The compiler analyses expressions depth first. It checks 
 arguments before checking whether the expression is callable. 
 If you change `FT(0)` into `FT("")`, it reports "Error: cannot 
 implicitly convert expression `""` of type `string` to `int`" 
 which hides the "type `void(int)` is not an expression" error. 
 This has always been the case.

 Conversely, once you fix the argument list in the test case of 
 20875 you will get the "is not an expression" error. Also note 
 that calling a type is not necessarily an error, it's fine when 
 you don't actually need the value. For example:

 ```D
 alias T = typeof(typeof(res.front)());
 ```

 If you think the "is not an expression" should have priority 
 over the argument list error, that's a valid enhancement 
 request, but it would be harder to implement (goes against the 
 natural bottom up analysis order of the compiler) and would be 
 a separate change. The bugfix simply follows existing 
 architectural choices of dmd.

 I don't appreciate the rabble rousing on the forum by the way. 
 I would have preferred a review comment on GitHub, or a new 
 issue asking to improve the error message. I like working on 
 open source, but it can be stressful for me when I feel like 
 there's a large group of strangers watching me, eager to point 
 out every way I'm doing things wrong.


This happens all the time, not just in tech, so try not to get 
too upset about it. When your work is public, people will praise 
you for good stuff but also criticize your decisions.


Your contributions are very much appreciated, thanks Dennis!
Apr 08