• Universal agreement to remove view bounds: https://groups.google.com/d/topic/scala-internals/hNow9MvAi6Q/discussion
• IDE quick fix: https://groups.google.com/d/topic/scala-ide-dev/3aBzKPDJnlU/discussion (Depends on the addition of this warning to have something to act on)
• Not mentioned in the Scala style guide, therefore nothing to update

Todo:

• Migrate our codebase
• Update the FAQ: http://docs.scala-lang.org/tutorials/FAQ/context-and-view-bounds.html
• Update the spec (§7.4)

I think this commit would use a non-empty description.

@xeno-by Updated.

@soc Looks like the proposed fix in the error message still lacks a type parameter :)

Weird ... I wonder whether I messed something up. The tests are gone completely. I'll redo this commit again. Sorry guys!

Ok, extremely weird. I can't get the tests to fail in partest, the compiler doesn't emit the warnings. Did anything change recently in regard to partest?

Not sure what you mean by "doesn't emit the warnings." I tried your branch and it WFM.

I'll try to PR to the PR, but if I fail, I suggest this version of the warning or similar:

        if (contextBoundBuf ne null) {
          while (in.token == VIEWBOUND) {
            contextBoundBuf += atPos(in.skipToken()) {
              val t = typ()
              def discourage() = {
                val msg = "Use an implicit parameter instead."
                val eg = s"Instead of `def $owner[$pname <% $t](p: $pname)`, use `def $owner(p: $pname)(implicit ev: $pname => $t)`."
                if (settings.future) syntaxError(in.offset, f"View bounds have been removed. $msg%n$eg")
                else deprecationWarning(in.offset, f"View bounds are deprecated. $msg%n$eg")
              }
              discourage()
              makeFunctionTypeTree(List(Ident(pname)), t)
            }
          }

where the change is to use the bounds in the example and use platform newline.

I will also suggest .flags with -deprecation with updated checks, or fix the test, or if testing a deprecated feature, deprecate the Main to suppress the warning. I forgot to check if view bound is being tested by these tests.

Thanks @som-snytt. I have added tests locally to test/files/neg, but the issue is that they don't fail as expected. I'm starting to wonder whether partest somehow decided to pick the last stable Scala build instead of the one built from the source.

Of course, by fail as expected, you mean succeed by failing (as expected). If these two tests emit deprecations, then any neg test will, too, right? I'll try it, since it's set up.

Meanwhile, I'm not sure about the sample value param list; I considered an ellipsis instead:

iterator-from.scala:14: warning: View bounds are deprecated. Use an implicit parameter instead.
Instead of `def testSet[A <% Ordered[A]](p: A)`, use `def testSet(p: A)(implicit ev: A => Ordered[A])`.
  def testSet[A <% Ordered[A]](set: SortedSet[A], list: List[A]) {

Yes, to confirm, just copying over iterator-from to neg with -Xfatal-warnings and -deprecation will fail (i.e. correctly).

I did notice it has an inline warning filter; remember warnings are only emitted once for a location, so a test could theoretically emit inline warning (for instance), have it filtered by partest, but then because you were really interested in an another warning you expected at the same position, you wind up confused.

I don't know yet if that happened here, but it's a big caveat.

To run partest from the command line as it will be done in the test suite:

SCALAC_OPTS=-optimize ./test/partest path/to/test

If the test fails spuriously under -optimize, you can use a .flags files with -Ynooptimise.

Isn't that cheating? #partest -optimise might work in any case.

If you lose patience with it, just add #partest true to the checkfile and filter: .* to the test header. Something like that should work well enough so you won't get caught cheating, which is what they throw you in the slammer for, i.e., getting caught.

I'm not sure whether / how -optimize is related to this PR. In general, there are occasional good reasons to limit a test to -Ynooptimise, e.g. fine grained checks on trees or bytecode that would vary otherwise in ways not pertinent to what's being tested.

Ok, found my stupid mistake (if I want to test the deprecation of <% I shouldn't use <: in the tests ...).

@som-snytt I adopted some of your wording because it is better.
I refrained from trying to build specific migration messages for now, because imho it is very hard to get a robust solution that early in the parser and I think it's better to have something clearly marked as a general example instead of trying to use the code in question and offering an imprecise and probably incorrect advice.

I think if you managed to get something working which would be robust for all inputs, e. g. def g[C, B <: C, A <% B : Numeric](a: A) = null this would be absolutely fantastic because then the IDE could take it's refactoring advice straight from the compiler.

Review by @gkossakowski, please.

@soc: I'm moving to Europe next week so I won't have time to look into this. Please assign other reviewer. @retronym, could you have a look?

@gkossakowski Thanks for the notice! @retronym, could you have a look?

PLS REBUILD/pr-scala@801866c

(kitty-note-to-self: ignore 24949656)
🐱 Roger! Rebuilding pr-scala for 801866ce. 🚨

I'm still in two minds about merging this without giving a more specific instruction about how to fix it.

One task that is definitely still needed is a commit that migrates usages of view bounds in our codebase to implicit parameters.

Yep. This is exactly what this commit is about. There already exists IDE code for both a quick fix and a refactoring. That code depends on getting a warning from the compiler to trigger properly.

This is what this commit enables:

• Allow easier testing of the migration code/advice
• Make automated actions solid
• Move the appropriate parts of the then well-tested migration code into the compiler, so that all tools benefit from it

How about you in the first step you make it deprecated with -Xfuture and do nothing otherwise. Then, when the migration tools are shown to work, we can take the next step, hopefully before 2.11.0.

I'm happy for this to go in under -Xfuture. Let us know how the migration tool works out and we can consider the next step.