Deprecate no space between expression and ? in ternaries

[ararslan]

Discussing with @JeffBezanson and @StefanKarpinski, 0.7 will have this deprecation warning, then in 1.0 x? will mean something different (likely Union{T,Null}) rather than an error.

[JeffBezanson]

+100 to adding the spaces to the code in Base. The deprecation might need more discussion.

[iamed2]

Regarding the deprecation:

It might be odd for people coming directly from 0.6 to 1.0 getting this:

julia> x? 1:3
ERROR: syntax: extra token "1" after end of expression

Perhaps we could have a two-stage deprecation where this error prints some extra information like "using ternary syntax without whitespace was deprecated in 0.7"?

[ararslan]

I think the goal with 1.0 is to have no deprecations at all. Typically we do two-stage deprecations, but in this case I think it's something we'd like to get into 1.0, so in order to make that happen we need to bypass our standard deprecation practice a bit. It's unfortunate but worth it IMO.

[tkelman]

Syntax that is an error in 1.0 could probably be given a non-error meaning in 1.x. A syntax error is a questionable thing to depend on.

[ararslan]

If we want to have a good story for missing data in 1.0, being able to write Int? to mean Union{Int, Null} (or whatever) would be much nicer than always having to write out the full type. It'd be a little unfortunate to have to wait for 1.x (for x > 0) for a better syntax for something we want in 1.0.

[iamed2]

By two-stage deprecation I meant:

1. Deprecation warning
2. New behaviour, but in cases which would work with old behaviour but error with new behaviour, generate helpful error messages

[ararslan]

Ah, so in 1.0 make sure that x? 1:3 emits a message more helpful than "extra token after end of expression"? That sounds good to me. 👍

[Sacha0]

Perhaps add spaces around the colons as well?

[ararslan]

Ah, I missed that. Yes, good idea, thanks.

[ararslan]

@JeffBezanson Do you have reservations about the deprecation? What kind of discussion needs to take place here?

[Sacha0]

lgtm (modulo the parser changes, which I have not pored over )! :)

(Discussion elsewhere suggests consensus formed in the affirmative re. the deprecation since the initial comments on this PR.)

[tkelman]

We shouldn't plan on introducing any new features between 0.7 and 1.0, to avoid making that take any longer than just removing deprecations.

[ararslan]

I feel like this is something we should really have in 1.0. I know the timing skirts around our usual things a bit, but I really think it's worth it in this case. Having a good story for missing data and a sensible way to express it is pretty crucial in a scientific language and thus far we've been lacking in that area. Being able to write T? = Union{T, Base.Null} rather than writing out the Union will make 1.0 that much more appealing for statisticians, data scientists, etc.

[ararslan]

But at any rate, we can cross that bridge when we come to it. Since just the deprecation here seems pretty uncontroversial, I'll go ahead and merge this.

[tkelman]

That definition doesn't have to be in base, if the operator is officially undefined for 1.0. Adding features between 0.7 and 1.0 is making that into a separate release cycle which would go against the publicly announced plan.

I think syntax sugar is far from the data ecosystem's biggest problem that needs to be solved before 1.0.

[ararslan]

I think syntax sugar is far from the data ecosystem's biggest problem that needs to be solved before 1.0.

Certainly. The rest is being actively worked on and at this point I think we have a fairly solid plan.

[StefanKarpinski]

Not allowing ourselves to claim back syntaxes that are deprecated in 0.7 is like trying to work with both arms tied behind our backs. I think we should plan to reclaim some syntaxes, but we need to have PRs for them ready to go when we tag 0.7, then merge them and tag 1.0. Actually, they should all be ready on a single branch.

[tkelman]

So much for 1.0 == 0.7 without deprecations then, it's actually going to be 0.7 without deprecations plus some to-be-determined amount of new stuff? Everything that gets added requires testing (in a few trial use cases, not only within base), documenting, stabilization before it's release-worthy. aka a separate release cycle which we've said there wouldn't be between 0.7 and 1.0.

[StefanKarpinski]

Please don't be so dramatic, the key is that the releases come out back-to-back and have minimal differences. Even making T? not a parse error and an operator as you yourself suggested above requires parser changes between 0.7 and 1.0. A few parser changes that we've staged and tested beforehand doesn't make it a full release cycle. Chill.

[JeffBezanson]

To me the important thing is that code with no warnings on 0.7 also works on 1.0. If you fix the warnings, your code will not contain X?, so adding a meaning for X? is pretty unlikely to break anything. But if we need more time for nullable stuff to settle we could also add it in 1.1.

[tkelman]

If 0.7 is in feature freeze for a while, a lot of things will be pending and "ready." That feature freeze should extend across both 0.7 and 1.0 or the schedule is going to slip further.