With !zero? are you looking to indicate both that the function is a predicate and mutating? “What the heck is going on here” is a reasonable question.
Well, to me it looks like it is modifying the even function, in a way similar to prepending a !.
I also stand by the claim that you’re not asking a question, you’re creating a recipe, if this do that. Since branches so often have if in front of them, a question mark gets weird: if this? It’s jarring. I’m precisely talking about phrasing, and your examples demonstrate that the proposed convention encourages an unnatural rephrasing.
I’m not saying all predicates need an is in front of them. Use it if it clarifies. You can also use has for example, or does or whatever.
1 Like
That is what it would look like with the proposed convention when you are negating a predicate. If you want to check if x is different from zero, today you write:
if !iszero(x)
The proposed convention would yield
if !zero?(x)
Ah, yes I see what you mean. Though, I think if ! zero?(x) clarifies things.
I think that looks a bit strange in cases like this:
map(! zero?, -2:2)
I don’t think returning a boolean is all that special. Anyway, what about haskey. Should that be key? ?
The thing that is special about returning booleans is that it happens a lot and its almost always used to control the flow of your program so being able to spot predicates quickly accelerates your reading and understanding of the code.
I feel less enthused about the possibility of using ? for predicates than I did last night. I somewhat agree with the assessment that the ? character would seem to indicate some special property of a function, and I’m a bit dubious that returning a Bool qualifies.
Another thought (that it’s probably far too late for, but that I’ll throw out there anyway) is to have a special character prepended to arguments which specify the return type. For instance
empty(^Bool, A) # isempty(A)
which admittedly seems pedantic in this example, but has the benefit of making it clear to anyone reading the code, including the compiler exactly what such functions should return. Of course this pattern can be extended beyond Bool. Note this is not the same thing as empty(A)::Bool because that would simply be an assertion, while the ^Bool would also act as an argument.
One observation I have now that I’ve read quite a lot of Julia code is that I really hate when people don’t put type assertions on arguments in cases where only a particular type would make any sense. It may not make too big a difference to the compiler, but it’s much easier for humans to read.
Regardless of any of this, I definitely think deprecating ternary operators with no spaces is a good idea. As I pointed out in the issue, : must have spaces, so it makes sense to require this of ? as well.
2 Likes
to requiring spaces around the ? as well as the : for the ternary operator
Newbies tend to ask what’s up with the ! at the end of some function names. It looks like it perhaps does something to the previous function automatically. It’s just a convention, but it indicates something that is a pretty big deal…
I’m a bit late to this party but I agree here. Actually the ! convention is already a bit problematic, because there’s nothing to stop someone from making a function that mutates an argument but doesn’t have ! in the name, nor making a function with ! in the name that doesn’t mutate.
Ultimately, I’ve come to think this particular convention is well worth it, because as you say modifying arguments is a big deal and worth flagging. But I’d be really wary of expanding on conventions like this, even if they’d be convenient. The more unenforced conventions, the more opportunity for mistakes to get made.
4 Likes
I agree with this. I would hope the questionmark never gets allowed in names, as it reads intuitively like an operator to me (and it even is used as an operator).
5 Likes
As a heads up, it’s quite unlikely that ? will be allowed as part of variable names, since postfix ? is being claimed in Julia 1.0 as T? == Union{T, Null} (see this data ecosystem announcement). In anticipation of this, omitting whitespace between an expression and the ? in a ternary has been deprecated in 0.7.
5 Likes
I agree, maybe better would be:
map(!?zero, -2:2)
for “map_where_not_is_zero” (note, here no longer a question needing ? at the end).
We’re just used to having ? at the end of questions (but also “Is” as part of), with the question really:
“Is it zero?”
Or the same one in Spanish (just showing nothing special about end-placement, not that we should have at both ends):
“¿Es cero?”
“¿is it zero?”
The topic here is “Question mark in variable names”, I think that should be disallowed, only ok for function names, say then only in front (not sure should be in the back, at least not allow both or any in the middle). [In the future Julia seems to be adopting using ? at the end of variables at least, for other uses.]
On “I’m a bit dubious that returning a Bool qualifies.” I disagree, Booleans are very special, and having ? as part of the function name in a defined place, should always indicate it returns a Bool. Defining some other return type (or returning a different type in an type-unstable way) otherwise should be an error when you define the function.
1 Like