After fixing gratuitous postfix in the compiler:

/var/folders/2_/xb149z895wb5f1y632xp2bw40000gq/T/sbt_19b03fbd/xsbt/Compat.scala:152: error: postfix operator headOption needs to be enabled
by making the implicit value scala.language.postfixOps visible.
This can be achieved by adding the import clause 'import scala.language.postfixOps'
or by setting the compiler option -language:postfixOps.
See the Scaladoc for value scala.language.postfixOps for a discussion
why the feature needs to be explicitly enabled.
          } headOption
            ^

Maybe @dwijnand knows if it's possible to set the scalac options for this compilation. It's ironic that the compatibility layer uses an incompatible feature.

Maybe @dwijnand knows if it's possible to set the scalac options for this compilation.

Nope, it's not configurable: https://github.com/sbt/zinc/blob/v1.1.5/internal/zinc-compile-core/src/main/scala/sbt/internal/inc/AnalyzingCompiler.scala#L350

It's ironic that the compatibility layer uses an incompatible feature.

Hardly fair: you're using the legacy 0.13 version of sbt. Not a problem in sbt 1: sbt/zinc@ecf121a#diff-569dc93f697b5a143e904e517b998e1dL124.

Thanks for checking, @dwijnand

I think the irony is still apt, since that class is for 2.9-2.11 compatibility but doesn't negotiate SIP 18; but it wouldn't be fair to stretch the point.

I'm not sure if scalac will upgrade to 1.1.x soon or if needing a 0.13.18 for 2.13 would be OK.

not sure if scalac will upgrade to 1.1.x soon

more reason to land #6256

if needing a 0.13.18 for 2.13 would be OK

quite probably not

I'm not sure if scalac will upgrade to 1.1.x soon or if needing a 0.13.18 for 2.13 would be OK.

Even if scalac migrates to sbt 1.1.x, IIUC this change would still break users builds using sbt 0.13.x with Scala 2.13.0-M4+.

Yes, but if 0.13.18 is fixed, users can upgrade without much burden.

I'll look into whether a special dispensation is possible for sbt, which wouldn't be the first time.

It works with local bootstrap, but no one has complained that feature warning can double-report because the explanatory part fools the reporter. (1 + must past twice through typer; the workaround is to cause the first feature warning with something benign like "hello, world" length.)

$ skalac -feature xsbt/Compat.scala
$ scalac -feature xsbt/Compat.scala
xsbt/Compat.scala:6: warning: postfix operator + should be enabled
by making the implicit value scala.language.postfixOps visible.
This can be achieved by adding the import clause 'import scala.language.postfixOps'
or by setting the compiler option -language:postfixOps.
See the Scaladoc for value scala.language.postfixOps for a discussion
why the feature should be explicitly enabled.
    List(1,2,3) map (1 +)
                       ^
xsbt/Compat.scala:6: warning: postfix operator + should be enabled
by making the implicit value scala.language.postfixOps visible.
    List(1,2,3) map (1 +)
                       ^
two warnings found

Golden tickets need to be handed out before checking them more vigorously: the sbt opt-out commit should go before the "more opt-in" commit. Also please split commits into boyscouting and strictly core changes, especially when we're flipping bits.

Finally, kill your darlings, as William said (Faulkner, not the man in black): "Make postFixOps more opt-in" is a bit too clever.

This is branch order, but github shows date order. Maybe I broke something. The bit is flipped in its own commit, or do you mean you'd like the required test fixes to precede it?

Edit: reminder, don't forget to change title back to Post-postfix.

commit d91f4a4bfbd3a9b802ecebb9a9b6044c08eac0db (HEAD -> issue/post-postfix, origin/issue/post-postfix)
Author: Som Snytt <som.snytt@gmail.com>
Date:   Fri Jun 1 15:56:20 2018 -0700

    Make postfixOps more opt-in
    
    Require postfixOps feature opt-in instead of just warning.

commit fdcf987c246bb8db2cfc3f2db9a67cfdfe62128e
Author: Som Snytt <som.snytt@gmail.com>
Date:   Fri Jun 1 17:22:38 2018 -0700

    sbt gets a by

commit b3ca049600577a8227609e747868277708a28cd4
Author: Som Snytt <som.snytt@gmail.com>
Date:   Thu May 3 15:36:53 2018 -0700

    Reduce postfix ops in tests

commit b64946344b8b7b7171952a8beee649f84ac3f871
Author: Som Snytt <som.snytt@gmail.com>
Date:   Wed Apr 25 21:13:58 2018 -0700

    Reduce postfix ops
    
    Usages unguarded by language import. In the same
    neighborhood, reduce infix as well.

Ah, right! GH using date order is really unfortunate. Scabot just blindly follows it. I assume there's a rebase option to fix this?

For the boy scouting, I was referring to the boolean algebra wizardry in the bit flip commit. It's not a big deal, but in general it's just nicer for reviewing to separate behavior changes from cleanups. Both are appreciated, just better separate.

Note to self: t5675 is what rang a bell for the double-count issue for -feature over on #6635

I assume there's a rebase option to fix this?

I think it's possible to fix this with --committer-date-is-author-date.

at https://contributors.scala-lang.org/t/lets-drop-postfix-operators/1457/11?u=sethtisue @LPTK expressed skepticism about the desirability of actually removing this in 2.14.

I think the other changes in this PR take care of disarming the footgun. so maybe the actual removal under -Xsource:2.14 isn't really necessary? I don't have a strong feeling about it, but I think it's worth a last thought before merge.

note also @sjrd's remarks at https://contributors.scala-lang.org/t/lets-drop-postfix-operators/1457/2?u=sethtisue, which @LPTK echoed

one more thought: I think the error message should be more explicit that this "feature" is actually highly undesirable, likely to be removed in a future Scala, and is still supported at all only for backward compatibility and for no other reason.

this isn't a "proceed, but with caution" type thing anymore like higherKinds and so on... this one is a "no, really, please don't"

@SethTisue Please take a look at the doc change in the last commit.

@adriaanm Moved the post-starr commit to the linked PR, in case that's the right thing to do.

Please take a look at the doc change in the last commit

LGTM except that I'd suggest appending " (not recommended)" here

+ *   - [[postfixOps          `postfixOps`]]          enables postfix operator notation

OK, I'll add " (not Seth-approved)" or " (not recommended by Seth, who knows)", whichever you prefer. I guess I'll know your preference by your reply to this comment. Actually, following Lacan, it should be, " (not recommended by Seth, the subject supposed to know)".

the -Y is an other

@adriaanm @SethTisue if we can move this along, I'll have time to help with community build issues.

I feel no special animus toward postfix, but hoping for clarity.

It needs restarr for the other PR to put the nail in the coffin.

does this PR actually make it an error? I'm not seeing that it does:

> scala
[info] Running scala.tools.nsc.MainGenericRunner -usejavacp
Welcome to Scala 2.13.0-20180716-190107-b9e039c (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_172).
Type in expressions for evaluation. Or try :help.

scala> List(1) max
               ^
       warning: postfix operator max should be enabled
       by making the implicit value scala.language.postfixOps visible.
       This can be achieved by adding the import clause 'import scala.language.postfixOps'
       or by setting the compiler option -language:postfixOps.
       See the Scaladoc for value scala.language.postfixOps for a discussion
       why the feature should be explicitly enabled.
res0: Int = 1

oh, is that because "we'll have to release a new starr"? if so, then 1) can you update the PR title, and 2) yes, let's merge this.

Yes, #6831

postfix ops are looking really nervous now

Cool~