Skip to content

Fix Unexpected ctor storing error value#8

Merged
tchaloupka merged 1 commit into
tchaloupka:masterfrom
PetarKirov:fix/unexpected-self-init
May 18, 2026
Merged

Fix Unexpected ctor storing error value#8
tchaloupka merged 1 commit into
tchaloupka:masterfrom
PetarKirov:fix/unexpected-self-init

Conversation

@PetarKirov

Copy link
Copy Markdown
Contributor

Summary

The Unexpected exception constructor at source/expected.d:1312 had this.error = error; — assigning the field to itself rather than the value parameter. As a result, the error value was never actually stored on the exception.

Newer compilers now emit:

source/expected.d(1312,13): Deprecation: cannot initialize field `error` with itself
             this.error = error;
             ^

This will eventually become a hard error.

Fix

-            static if (isAssignable!(string, T)) super(forward!value, file, line);
+            static if (isAssignable!(string, T)) super(value, file, line);
             else super("Unexpected error", file, line);

-            this.error = error;
+            this.error = forward!value;

I also dropped the forward!value from the super(...) call. Otherwise we'd be forwarding value to super and to this.error, which would use value after a potential move. The static if branch only fires when T is assignable to string (slice types — no meaningful move semantics), so passing value by ref to super is safe.

Test plan

  • dub test — 43/43 pass
  • dub build — clean, no deprecation

`this.error = error` referenced the field itself, not the `value`
parameter — so the error was never stored, and newer compilers warn:
"Deprecation: cannot initialize field `error` with itself".

Forward `value` to the field instead, and drop the now-redundant
`forward!value` from the super call (it's only reached when T is
assignable to string, i.e. a slice type with no move semantics).
@tchaloupka
tchaloupka merged commit ef42338 into tchaloupka:master May 18, 2026
7 checks passed
@tchaloupka

Copy link
Copy Markdown
Owner

thanks

@PetarKirov

Copy link
Copy Markdown
Contributor Author

thanks as well for the quick merge @tchaloupka! Can you tag v0.4.1?

tchaloupka added a commit that referenced this pull request May 18, 2026
Adds assertions to the "Throw" unittest checking that the error value is actually stored on the thrown Unexpected exception, for both the string and non-string error types.

This reproduces the self-assignment bug fixed in #8: without that fix the new assertions fail at the `ex.error == ...` checks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants