Symbol literals supported pattern matching:

    'foo match {
      case 'bar => ...
    }

This shorthand syntax, using StringContext, won't compile:

    sym"foo" match {
      case sym"bar" => ...
    }

[error] method sym is not a case class, nor does it have an unapply/unapplySeq member
[error]       case sym"bar" => ...
[error]            ^
[error] one error found

It is possible to match using the Symbol.apply constructor.

    sym"foo" match {
      case Symbol("bar") => ...
    }

Is it possible to make sym a syntax that supports pattern matching? I don't think it would be a big loss to lose string interpolation when constructing symbols.

You can have an unapply on a string interpolator, see for example #7387

@smarter Exciting! Thanks for pointing that out.

Using this syntax throughout the compiler was successfully experimented with in #7499.

I tried using this syntax in the 2.12 version of the community build, see scala/community-build#827

I forked 24 community projects that had literal symbols in their build. I added the new symbol syntax to these builds, and this resulted in 92 projects being built successfully.

• acyclic
• akka
• base64
• curryhoward
• fansi
• fastparse
• geny
• grizzled
• jackson-module-scala
• lift-json
• magnolia
• pcplod
• pprint
• scala-parser-combinators
• scala-stm
• scalamock
• scalatags
• scalatest
• sourcecode
• specs2
• spray-json
• twirl
• utest

There was one project of the 24 that the new symbol syntax could not be made to work:

• shapeless

Shapeless will either require some significant re-architecting to support symbols or dropping symbol literals entirely. I am not an expert, but I presume it is because Shapeless expects symbol literals to be available at the compiler/reflect level and not at runtime.

There were 85 builds that didn't run in the community build because a dependency failed to build or because shapeless can't build.

Shapeless will either require some significant re-architecting to support symbols or dropping symbol literals entirely. I am not an expert, but I presume it is because Shapeless expects symbol literals to be available at the compiler/reflect level and not at runtime.

/cc @milessabin

I may have overstated the situation in my last comment. There's evidence that Symbol.apply will work for Shapeless as an alternative to dropping symbol literals.

thanks Aaron for your diligence on this. I think #7395 will be merged soon as well

I am saddened that this feature of Lisp heritage will likely go away, but despite my best efforts I couldn't find a compelling reason to keep it. There's a chance something could still come up that would preclude it. I'm not an expert, but I would bet against such a possibility.

it's a bit sad we can't backport the new interpolator to 2.12.x, because bincompat. I guess cross-builders can use the Symbol constructor

It could also be implemented in a compat library.

I find https://contributors.scala-lang.org/t/proposal-to-deprecate-and-remove-symbol-literals/2953/22 a pretty compelling argument against this PR (note the author on both ;-)). Should we revert this PR to avoid introducing too many ways of doing the same thing, especially since it likely won't help cross-building?

reverted by #7917