Skip to content

ambiguous in line 'sb.Append($"Test1\n");' #283

Closed

Description

@SMAH1

Code of csproj and Program.cs:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <OutputType>exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <InvariantGlobalization>true</InvariantGlobalization>
    <PublishAot>true</PublishAot>
    <IsAotCompatible>true</IsAotCompatible>
    <LangVersion>preview</LangVersion>
    <PlatformTarget>x64</PlatformTarget>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="LinkDotNet.StringBuilder" Version="3.4.1" />
  </ItemGroup>

</Project>
using LinkDotNet.StringBuilder;

using scoped ValueStringBuilder sb = new(100);
int age = 42;
sb.Append($"Test1\n");
sb.Append($"Test2 {age}\n");
sb.Append("Test3\n");
sb.Append("Test4\n".AsSpan());
Console.WriteLine(sb.ToString());

Compile AOT in Windows (dotnet publish -r win-x64 -c Release -o .\publish) : OK
Compile AOT in linux (dotnet publish -r linux-x64 -c Release -o ./publish) : Error

/..../Program.cs(5,4): error CS0121: The call is ambiguous between the following methods or properties: 'ValueStringBuilder.Append(scoped ReadOnlySpan<char>)' and 'ValueStringBuilder.Append(ref ValueStringBuilder.AppendInterpolatedStringHandler)'

in line:

sb.Append($"Test1\n");

Extran info:

.NET SDK:
 Version:           9.0.112
 Commit:            191254d648
 Workload version:  9.0.100-manifests.b3871ecb
 MSBuild version:   17.12.50+191254d64

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  22.04
 OS Platform: Linux
 RID:         ubuntu.22.04-x64
 Base Path:   /usr/lib/dotnet/sdk/9.0.112/

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.11
  Architecture: x64
  Commit:       191254d648

.NET SDKs installed:
  9.0.112 [/usr/lib/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 9.0.11 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 9.0.11 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

Activity

  1. linkdotnet commented on Mar 8, 2026

    @linkdotnet
    Owner

    Interesting - unfortunately I don't have a x64 machine right now at my disposal to verfiy that (on my Mac I can't publish against win-x64 and get errors from clang when targeting linux-arm64 or linux-x64).

    What happens if you
    a) Update the sdk to the latest patch release of 9.0.x
    b) Use net10.0 as target?

  2. hiSandog commented on Jul 4, 2026

    @hiSandog

    The ambiguity around sb.Append($"Test1\n"); likely needs a parser test that distinguishes interpolated strings, escape sequences, and line terminators. A minimal fixture should include normal strings, interpolated strings with no holes, interpolated strings with holes, and verbatim/raw strings if supported. That would prevent a fix for newline escaping from accidentally changing overload or token selection for interpolated strings.

  3. linkdotnet commented on Jul 4, 2026

    @linkdotnet
    Owner

    Guess I found the issue (also looking at System.Text.StringBuilder) and the issue stems more from C# 13 and earlier. The basic fix: add a new Append(string?) version just like STB.

    We could come around end of year and remove obsolete .net versions and assume C#14 is around

  4. linkdotnet commented on Jul 4, 2026

    @linkdotnet
    Owner

    Release 3.4.2 will be out soon

  5. Joy-less commented on Jul 4, 2026

    @Joy-less
    Contributor

    In case you don't want to add those extra overloads, you could alternatively add an [OverloadResolutionPriority] attribute to the ReadOnlySpan<char> overloads. It should be fine as it is though.

  6. linkdotnet commented on Jul 4, 2026

    @linkdotnet
    Owner

    In case you don't want to add those extra overloads, you could alternatively add an [OverloadResolutionPriority] attribute to the ReadOnlySpan<char> overloads. It should be fine as it is though.

    Good thought - but it wouldn't work with the net8.0 target we still currently have

  7. Joy-less commented on Jul 4, 2026

    @Joy-less
    Contributor

    Good thought - but it wouldn't work with the net8.0 target we still currently have

    .NET 8.0 will go out of support on 2026/11/10 (only 4 months from now) so you could remove support for .NET 8.0 (and .NET 9.0) early if you want. Otherwise, we can just continue with your extra method approach. :P

  8. linkdotnet commented on Jul 4, 2026

    @linkdotnet
    Owner

    It will be removed :D don't see a reason having that if we drop old framework versions

  9. Joy-less commented on Jul 4, 2026

    @Joy-less
    Contributor

    Considering the version 3.4.2 is now released with these overloads, I think they should stay in. No need to drop old framework versions for now.

  10. linkdotnet commented on Jul 4, 2026

    @linkdotnet
    Owner

    Nono - anyway it would be a major release and I will wait until net8/9 is EOL. So a few more months to go

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

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions