Support (a subset of) interpolated strings in Attribute parameters

[baronfel]

I propose we allow using interpolated string expressions in Attributes, as long as the constructs involved in the interpolated string are valid for use as literals.

After this change, the Obsolete attribute parameter on the Deprecated member below would be valid:

/// Represents information about programming constructs like variables, classes,
/// interfaces etc.
type SymbolInformation =
  { /// The name of this symbol.
    Name: string

    /// The kind of this symbol.
    Kind: SymbolKind

    /// Tags for this symbol.
    Tags: SymbolTag [] option

    /// Indicates if this symbol is deprecated.
    /// @deprecated Use tags instead
    [<Obsolete($"Use nameof(Unchecked.defaultof<SymbolInformation>.Tags) instead")>]
    Deprecated: bool option

    /// The location of this symbol. The location's range is used by a tool
    /// to reveal the location in the editor. If the symbol is selected in the
    /// tool the range's start information is used to position the cursor. So
    /// the range usually spans more then the actual symbol's name and does
    /// normally include things like visibility modifiers.
    ///
    /// The range doesn't have to denote a node range in the sense of a abstract
    /// syntax tree. It can therefore not be used to re-construct a hierarchy of
    /// the symbols.
    Location: Location

    /// The name of the symbol containing this symbol. This information is for
    /// user interface purposes (e.g. to render a qualifier in the user interface
    /// if necessary). It can't be used to re-infer a hierarchy for the document
    /// symbols.
    ContainerName: string option }

The existing way of approaching this problem in F# is to not use interpolated strings and instead build up strings using concatenation of literal portions.

Pros and Cons

The advantages of making this adjustment to F# are consistency in string handling across the language.

The disadvantages of making this adjustment to F# are extension of the compile-time computation feature of some interpolated strings, potentially raising end user confusion about when constructs are allowed to run.

Extra information

Estimated cost (XS, S, M, L, XL, XXL): M

Related suggestions: None that I could find

Affidavit (please submit!)

Please tick these items by placing a cross in the box:

• This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
• This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to the compiler and tooling repository
• This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it
• I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

• This is not a breaking change to the F# language design
• I or my company would be willing to help implement and/or test this

For Readers

If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.

[T-Gro]

Would the "subset" include more than concatenation?

[baronfel]

That's all my immediate use case required, bit I didn't want to immediately go to supporting arbitrary interpolated strikes because I know that won't work with the requirement that attribute arguments be literals, basically.