Julia: Allow '?' in variable and function names

[nsmith5]

Currently Julia does not support question marks inside of variable names. This was discussed a while ago , with support, but never pursued (#1539). The major implication of allowing this is that you can write predicate functions with a question mark. (eg. integer?(x) instead of isinteger(x)).

A little more discussion can be found on discourse. I wish I could accompany this with an RFC-like pull request, but I got quite lost in the parser in my attempt.

If this is pursued I really think trailing question marks should be pursued as the convention for predicates. They indicate very clearly that the function asks a question and, as previously discussed, the is- predicates can be awkward, leading to inconsistent usage (eg. contains).

[StefanKarpinski]

I would also really prefer writing predicates as property? but at this point this would be a very nasty deprecation since it would require putting spaces in all uses of the ternary operator.

[ExpandingMan]

Perhaps I'm extrapolating too much, but wouldn't the use of ? in a ternary operator without spaces be extremely rare? It seems like bad practice to do this as it is rather difficult to read, and it would certainly seem reasonable to disallow it.

[nsmith5]

Yeah, its unfortunate this wasn't tackled earlier, but if it doesn't happen pre-1.0 will it ever? I think the change is warranted. If someone changes the parser, I'd be happy to hunt through Base finding the offending statements. Obviously the deprecation issues for package managers is there, but as @ExpandingMan suggested, I wonder how often the space-less ternary operator was really used in the wild.

[quinnj]

I'd be in favor of requiring spaces around ?; I agree it only leads to more readable code and would definitely be something enforced in a juliafmt tool eventually.

[StefanKarpinski]

There's a surprisingly large number of instances of ternary operators without space after the ? in Base Julia, so this would certainly not be undisruptive.

[nsmith5]

I suppose the larger, and much more serious deprecation would be renaming of the predicates in the standard library should it be decided that following the property? convention is worth pursuing...

[ExpandingMan]

One observation is that ternary ?, : constructs without spaces seems like a fundamentally different thing than, for instance + and - without spaces due to the presence of the :. Because of the role of : in Julia, leaving no spaces for it seems bonkers (and would, I hope, result in syntax errors). Therefore it seems a bit inconsistent to allow ? without spaces.

[StefanKarpinski]

Right, that's the other thing about this – it's a multistep deprecation:

1. Version N+1: deprecate ? : without spaces.
2. Version N+2: make ? : without spaces an error.
3. Version N+2: deprecate isfoo in favor of foo?.
4. Version N+3: profit.

I'm not sure that much underpants collecting is worth it.

[ExpandingMan]

Ugh, when you put it that way, it sounds pretty painful...

[StefanKarpinski]

I know... not breaking people's code is a total drag 😬

[nsmith5]

Ok, so the question is: is it worth it? I still think that it is and as mentioned by @quinnj the deprecation of ? : seems justified on readability grounds if not for a change in predicate convention.

[nsmith5]

In other words: pleeeeeeeeeease :)

[ararslan]

Ok, so the question is: is it worth it?

Probably not.

FWIW I actually like that we use is for predicate functions, as it jives with the fact that nearly all function names are full words (or combinations thereof).

Regarding ?, the stats/data devs have our eyes set on postfix ? for T? == Union{T, Null}. But still, the massive code churn almost makes it a non-starter.

[ExpandingMan]

It sounds like movement should be made toward deprecating ternary operators without spaces, regardless of whether ? winds up being used for predicates, postfix, or whatever else.

[ararslan]

I'd tend to think that should be something that a linter/formatter should catch rather than the language itself.

[StefanKarpinski]

True, if we get widespread adoption of a standard formatting tool then this kind of change becomes much smoother since we can just tell people to run the formatter on their code before upgrading. I think I agree that deprecating ternary without spaces is a good idea regardless, but if we don't end up claiming that syntax, then disallowing it for no reason is just a bit weird.

[ZacLN]

This is already implemented for the julia-vscode plugin (on master) using CSTParser.jl, the auto formatting adds whitespace on ternary (and other appropriate) operators

[andyferris]

Stefan - we've combined steps 2 and 3 in the past, no? That would be v0.7 (step 1) and v1.0 (steps 2+3).

But yes, this needs to compete with nullables (prefix unary ?T might be a mutually compatible option for nullables). Predicate f? looks nice in the femtolisp code... hard to say what is best, but definitely "last chance" territory.

[StefanKarpinski]

Yes, that's why they're in the same version (N+2).

[ararslan]

I think at this point it doesn't make sense to introduce ? for predicates. The current style of using is* and other prose is well-established, so introducing another competing style is just asking for inconsistency and confusion.

[StefanKarpinski]

We could deprecate identifiers followed by ? without an intervening space in 0.7 and then make it an error in 1.0 (which will follow 0.7 immediately). That would allow us to use the syntax for something in the future without being too long a process now. We would possibly also want to deprecate and then disallow not surrounding the : in a ternary operator with spaces, although that's really an orthogonal issue.

[mkborregaard]

I also would like to raise the point that ? parses intuitively as an operator, to my eyes and possibly other's. It would be the only operator allowed in names, and there is already an easy, succinct and intuitive syntax for this (is...). Finally, there would be an unintuitive pattern where postpending ? means a question, but postpending ! (which I have learned to like) does not mean answer - it means something completely different, that the function modifies at least one of its arguments.