www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Discussing exception translation with GPT-5 mini: lazy void parameters

reply Forum User <forumuser example.com> writes:
After having a chat with GPT-5 mini (via duck.ai) about exception 
translation the AI came up with some strange examples. I then 
thought it would be a good idea if I tell the AI something new:

Well you can use UFCS to append the exceptionTranslator with a 
lazy argument this way:

```d
T translate (Ein, Eout, T) (lazy T t)
{
     try return t;
     catch (Ein e) throw new Eout (e.msg);
}
```

Then the AI tries to convince me that I need two template 
variants:

Yes — that's a neat, idiomatic D solution. A few concise 
suggestions to make it robust and idiomatic:

* Constrain template parameters to exception types and preserve 
ref/return semantics:

```d
T translate(Ein, Eout, T)(lazy T t)
if (is(Ein : Exception) && is(Eout : Exception) && !is(T == void))
{
     try return t;
     catch (Ein e) { throw new Eout(e.msg); }
}
```


*    Support void returns:

```d
void translate(Ein, Eout)(lazy void delegate() t)
if (is(Ein : Exception) && is(Eout : Exception))
{
     try { t(); return; }
     catch (Ein e) { throw new Eout(e.msg); }
}
```

[and even more code ...]

Only after insisting that the unified version is valid, compiles 
and runs as expected the AI abondons the field (but that means 
nothing) stating:

Agreed — if your implementation uses `lazy T t` and compiles/runs 
for `T = void` you don't need separate overloads. D allows `lazy 
void` and you can write a single template without static if by 
invoking `t` directly in a try/catch and either returning its 
value or returning nothing:

Example minimal unified form: [...]

This compiles because `return t;` is valid when `t` is a lazy 
void expression (it acts like `t(); return;`). Your approach is 
idiomatic and concise.

Is she right?
Apr 07
next sibling parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Tuesday, 7 April 2026 at 19:47:04 UTC, Forum User wrote:

 After having a chat with GPT-5 mini (via duck.ai) about...
 Is she right?


She?
Apr 07
parent matheus <matheus gmail.com> writes:
On Tuesday, 7 April 2026 at 21:28:34 UTC, Kapendev wrote:

 On Tuesday, 7 April 2026 at 19:47:04 UTC, Forum User wrote:

 After having a chat with GPT-5 mini (via duck.ai) about...
 Is she right?


 She?


For some reason I believe people tend to think AI as woman. It's 
interesting hearing people talking around where I live and I see 
this pattern when they say "she" (AI) answer this or "she" (AI) 
told me that.

Matheus.
Apr 07
prev sibling next sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Tuesday, 7 April 2026 at 19:47:04 UTC, Forum User wrote:

 After having a chat with GPT-5 mini (via duck.ai) about 
 exception translation the AI came up with some strange 
 examples. I then thought it would be a good idea if I tell the 
 AI something new:

 [...]


Small improvement: pass source exception into translated one, to 
not lose entire stack of exceptions.
Apr 08
parent reply Forum User <forumuser example.com> writes:
On Wednesday, 8 April 2026 at 07:33:56 UTC, Alexandru Ermicioi 
wrote:

 [...]
 Small improvement: pass source exception into translated one, 
 to not lose entire stack of exceptions.


```
T translate (Ein, Eout, T) (lazy T t)
{
    try return t;
    catch (Ein e) throw new Eout (e.msg, e.file, e.line, e);
}
```

right?
Apr 08
parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Wednesday, 8 April 2026 at 20:20:47 UTC, Forum User wrote:

 On Wednesday, 8 April 2026 at 07:33:56 UTC, Alexandru Ermicioi 
 wrote:

 [...]
 Small improvement: pass source exception into translated one, 
 to not lose entire stack of exceptions.


 ```
 T translate (Ein, Eout, T) (lazy T t)
 {
    try return t;
    catch (Ein e) throw new Eout (e.msg, e.file, e.line, e);
 }
 ```

 right?


Yep,

Also if you dont plan to have custom message for translated 
Exception, then just include only original exception in the 
translated one. file line should be part of stack trace, so 
there's no need to pass them, as well as message from original 
exception.
Apr 09
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 7 April 2026 at 19:47:04 UTC, Forum User wrote:

 After having a chat with GPT-5 mini (via duck.ai) about 
 exception translation the AI came up with some strange 
 examples. I then thought it would be a good idea if I tell the 
 AI something new:


Even when I use the latest GPT plus with thinking on and it still 
makes mistakes with some of D's idiosyncrasies, like how the 
const system works. It's less likely to make mistakes when 
whatever D is doing has some comparable way of doing it in other 
programming languages.
Apr 08
parent Forum User <forumuser example.com> writes:
On Wednesday, 8 April 2026 at 11:44:54 UTC, jmh530 wrote:

 [...]
 Even when I use the latest GPT plus with thinking on and it 
 still makes mistakes with some of D's idiosyncrasies, like how 
 the const system works.


Or naming a variable `out`. OpenAI's `codex` understands compiler 
error messages, so it autocorrected itself (herself, theirself?).


 It's less likely to make mistakes when whatever D is doing has 
 some comparable way of doing it in other programming languages.


GPT-5 (duck.ai): "If you prefer truly terse syntax like 
mayThrow().wrapException!AppError, you need mayThrow to return a 
wrapper type (or use a macro/preprocessor), because plain 
function return values can't be extended with new methods without 
wrapping them. The shown pattern is the usual idiomatic 
compromise in D." (I refrain from posting the "shown pattern" 
here).

Another questionable code I saw was this (from memory):

```d
string foo (scope string s)
{
     auto tmp = s.dup;
     // some modification on tmp
     return tmp.dup;
}
```
Apr 08