| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
runtime.Fetch was taught in expr-lang#952 to resolve a field on the concrete type held by an embedded interface, but the sibling builtin get() was left on the old standard-promotion-only lookup. get() is documented to differ from runtime.Fetch only in returning nil instead of panicking, so the same field access returned a value through member access (a.field) yet nil through get(a, "field"). Share the traversal by exporting runtime.FetchFromEmbeddedInterfaces and calling it from get()'s struct branch, mirroring Fetch. Adds a regression test under test/issues/952.
There was a problem hiding this comment.
The shared lookup keeps get() consistent with member access for fields behind embedded interfaces, while preserving nil for missing fields. The focused package tests and full suite pass.
Checked with:
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
The builtin get(obj, "field") doesn't resolve fields on the concrete type behind an embedded interface, while member access (...).field does. So for a value whose static type is unknown at compile time, (cond ? x : y).Value returns the value but get((cond ? x : y), "Value") returns nil — inconsistent access for the same field.
PR #952 added fetchFromEmbeddedInterfaces to runtime.Fetch but left its sibling get() behind; #935 had previously kept the two in lockstep. The fix mirrors #952's logic into get().
Verified both ways with go test: old returns nil, fixed returns the value; a missing field still returns nil (no panic), zero regression across the suite.