Skip to content

Some unsupported constructs return wrong values instead of erroring #8

Description

@odrobnik

Filed separately from #7 because this is a different and worse failure mode: these do not error, they return the wrong answer. A missing bridge is discoverable — the script stops and names the symbol. These produce plausible output that silently disagrees with stock Swift, which is especially dangerous given the stated goal of running LLM-generated code, where nobody is watching each line.

Found while probing bridge coverage on main (71605b2); each was checked against swiftc for the expected value.

Construct Stock Swift swift-script
Property wrapper with a clamping setter 10 50 — the wrapper is ignored, the raw value is stored
Result builder collecting statements "a b" "b" — only the last statement survives
"héllo".utf8.count 6 5 — returns the Character count
dict["k"] as? Int where the value is boxed Optional(1) nil — as? through an Optional fails

The README lists property wrappers and result builders under "What does NOT work", which is fair — but silently producing a different value is a stronger claim than "not implemented". Rejecting them outright (unsupported attribute @propertyWrapper) would be strictly better than honouring the declaration and ignoring its semantics, since the script author gets a boundary error instead of a wrong number.

The utf8.count and as? cases look like plain bugs rather than documented limits, and both are the kind of thing that shows up in string handling and JSON walking constantly.

Suggested resolution, in order of value:

  1. Make ignored constructs fail loudly. If @propertyWrapper and @resultBuilder semantics are not implemented, refuse the declaration rather than accept it and diverge.
  2. Fix String.utf8.count (and check utf16.count / unicodeScalars.count alongside it).
  3. Fix as? through Optional, which currently breaks the common dict["k"] as? T idiom.
  4. Consider a conformance test that runs the Examples/llm_probes/ scripts under both swiftc and swift-script and diffs the output, so divergence is caught by CI rather than by a reader noticing a suspicious number. Tools/bridge-metrics.sh already has a probes-pass axis for this — it is currently reporting zeros for an unrelated reason (see Foundation bridge coverage: five generator limits block most everyday scripting #7).

Two adjacent findings, lower severity: protocol extensions are rejected (cannot extend unknown type 'Greeter'), so protocol default implementations are unavailable; and actors, some P and generics — all listed as unimplemented in the README — actually work, so the README understates the interpreter.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions