Skip to content

0.17.1 nightlies remove #"…"# hash string literals (E0098) with no render-preserving migration path — the backtick replacement dedents indent-bearing prompt fragments #4591

Closed

Description

@BenSpex

Summary

0.17.1-nightly.20260824.b removes #"…"# hash string literals (error[E0098] removed language feature) with no migration path that preserves the rendered prompt:

  • baml fmt under the nightly does not migrate them — it exits 4 ("formatted 27 of 47 file(s); 20 failed") and leaves every hash literal in place (while reformatting the other 27 files, which is separate churn). There is no baml migrate command.
  • The obvious mechanical replacement — a multi-line backtick string — is not render-equivalent: backtick strings are dedented by their common indent, so an indent-bearing hash literal (used as a prompt fragment) renders differently after the rewrite.

Measured on a real prompt corpus (47 .baml files)

  • Census: 358 hash literals across 20 files; 36 of them multi-line (indent is part of the render); 127 contain a backtick (needs escaping in the backtick form); 17 contain " (needs \" in the quoted form); 0 contain ${ or $ or \.
  • Naive #"…"# → backtick migration: baml check green, but 11 of 33 rendered prompts change — proven exactly: same line counts, 28 differing lines, all of the form old == " " + new (a 4-space common-indent dedent of shared number-format fragments).
  • A render-neutral migration exists: every hash literal becomes ONE double-quoted string with \\, \", \n escaped. baml check exit 0 on both 0.17.0 and the nightly, and 0/33 render diffs. Cost: a ~2.3 kB prompt block becomes one enormous single line — prompt review as prose becomes materially harder. No indent-preserving multi-line form survives common-indent dedent unless a line sits at column 0, which changes the render.

Why this matters

For a prompt-corpus consumer, "render-identical" is the difference between a mechanical toolchain upgrade and a re-verification of every prompt against a live model (recorded-eval re-record). We just paid the 0.15→0.17 migration with a per-function byte-level render differential to avoid exactly that; this removal forces the same exercise again, and the only render-safe target form is much less reviewable than what was removed.

Asks (either would resolve it)

  1. A migration mode — baml fmt --fix-removed-features or similar — that rewrites hash literals to a render-identical form automatically; or
  2. A raw multi-line string form that preserves indentation (no common-indent dedent), so indent-bearing prompt fragments have a faithful home.

Environment

baml wrapper 0.2.0; 0.17.0 (accepts hash literals) vs 0.17.1-nightly.20260824.b (E0098); Linux x86_64. Related context from this consumer: #4588 (fixed on this nightly — thank you), #4589/#4590 (still reproduce on it), #4370.

Activity

  1. linear commented on Aug 25, 2026

    @linear
  2. codeshaunted commented on Sep 14, 2026

    @codeshaunted
    Contributor

    The dedenting difference does not seem intentional, I will look into that. As for the migration, I think we are working on a prompt or skill that should do very well at migrating codebases.

  3. sxlijin commented on Sep 24, 2026

    @sxlijin
    Contributor

    Will #4914 address the issues here? Since we don't have specific test cases, it's hard for us to make a call on whether the breakage is intended or not.

    We're trying to avoid supporting too many different string literal formats, and right now have opted to have (1) normal string literals and (2) prompt literals (multiline prompts get trim and dedent, single line prompts are verbatim).

    (Adding baml fmt migration support is unlikely to happen here- we think user's coding agents will be fine at this.)

  4. BenSpex commented on Sep 25, 2026

    @BenSpex
    Author

    coding agents should def. be fine with this. and it worked for my product.
    A documentation on the migration notice, agent friendly, should suffice here

  5. reopened this on Sep 29, 2026
  6. sxlijin commented on Oct 9, 2026

    @sxlijin
    Contributor

    BAML 0.21.0 gives multiline backticks v0-style rules for ordinary ASCII layout: it trims blank boundary lines and body-final spaces, and empties whitespace-only interior lines (#4914). This should be sufficient to allow doing migrating prompts in a straightforward way. Release notes: https://boundaryml.com/changelog.

  7. BenSpex commented on Oct 9, 2026

    @BenSpex
    Author

    Confirmed from our side, thanks. We had already migrated off hash literals: indentation-bearing fragments became quoted strings with explicit escapes (what the 0.21.0 migration note recommends), everything else became backticks. Rendering our whole prompt corpus through a local sink gives byte-identical request bodies on 0.21.0 and on the nightly we pinned before it. Nothing is left on our side, so this can be closed.

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

Metadata

Metadata

Assignees

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