Why static analysis is the way to go
Richard (Rikki) Andrew Cattermole
richard at cattermole.co.nz
Thu May 28 23:43:01 UTC 2026
On 29/05/2026 11:09 AM, H. S. Teoh wrote:
> On Fri, May 29, 2026 at 10:27:48AM +1200, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
>>
>> On 29/05/2026 10:17 AM, H. S. Teoh wrote:
>>> We keep finding problems with them, nothrow in particular had a
>>> bug report within the last couple of months that we have yet to
>>> find a solution for.
>>>
>>>
>>> Just curious, which bug is that?
>>
>> https://github.com/dlang/dmd/issues/17906
>
> But that bug has like 3-4 PRs referencing it. Surely we're making
> progress?
>
> OTOH, inferrence has never been dmd's strong suit. Throw(ha!) in
> recursion, and I'm not surprised it got all fouled up. This is
> somewhat, albeit remotely, related to the whole inheritable attributes
> thing. Ideally, you want a wildcard value representing "the
> nothrow-ness of this function" so that you can reason about recursive
> calls in a sane way afterwards. But there's no such thing in dmd, so
> you have just a bunch of hacks to try to skirt around the issue somehow.
>
> I wouldn't be surprised if similar issues exist with the other function
> attributes when the function is recursive. If .fun calls itself, is
> .fun pure? Well that depends on whether .fun pure to begin with.
>
> Has anyone tried recursion that isn't immediately obvious, like .fun ->
> .gun -> .fun, each level of which has nothrow-ness that depends on the
> callee? Betcha that doesn't work either.
>
>
> T
nothrow @nogc pure scope return all suffer from this.
dmd's architecture can't do inference as part of the type system.
But it allows it to be fast.
This was the final nail that decided that DIP1000 wasn't going to be
turned on.
Ideally I'd do a dconf talk about this, but alas, I did not win Lotto.
More information about the Digitalmars-d
mailing list