Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a more earnest attempt at renaming Void #25162

Merged
merged 3 commits into from
Dec 20, 2017
Merged

a more earnest attempt at renaming Void #25162

merged 3 commits into from
Dec 20, 2017

Conversation

StefanKarpinski
Copy link
Sponsor Member

@StefanKarpinski StefanKarpinski commented Dec 18, 2017

Closes #25082.

@StefanKarpinski
Copy link
Sponsor Member Author

This is going to be massively conflict-prone, so I've separated it into the manual change to base/boot.jl which is fairly finicky and the automatic part that changes all the things.

@ararslan ararslan added the kind:deprecation This change introduces or involves a deprecation label Dec 18, 2017
@StefanKarpinski
Copy link
Sponsor Member Author

Ok, the real deal this time. Can be easily rebased since the large rename step is scripted.

@Sacha0
Copy link
Member

Sacha0 commented Dec 19, 2017

(Would you like a manual review here, or are you confident in your transformations? :))

@StefanKarpinski
Copy link
Sponsor Member Author

I'm pretty sure this is correct, we just need to make a decision.

@JeffBezanson
Copy link
Sponsor Member

What I recall from when we had Nothing was that people would mistakenly use it instead of nothing fairly often. The similarity to python's None might contribute to this. Python also uses NoneType as the type of None, which helps avoid this confusion.

@StefanKarpinski
Copy link
Sponsor Member Author

StefanKarpinski commented Dec 20, 2017

If we have any other name ideas, it's pretty easy to change this since it's automated now. I still don't understand why nothing :: Nothing is uniquely problematic when we use that convention all the time. We're doing missing :: Missing, for example, and this pattern is now fairly well established –
maybe it wasn't so common back then. Back then using Nothing instead of nothing often kind of worked since they're both singletons and we weren't using nothing except for its non-printing behavior in the REPL. Now we are actively using it to indicate a missing value – and passing Nothing where nothing is expected will fail, so that particular issue may well have already resolved itself. Using NoneType for the type of None in Python is palatable partly because you don't talk about types much in Python. We have to write Nothing pretty often, so I think some brevity matters.

@JeffBezanson
Copy link
Sponsor Member

There are very few cases where a value and its type have the same name except for case. There are several pairs, like filter and Filter, or adjoint and Adjoint, where the two names have a different relationship, typically a function and the type of value it returns.

@StefanKarpinski
Copy link
Sponsor Member Author

There's an awful lot of support for this rename on the original issue – and a bit of dissent, but it's unusually lopsided. Perhaps people who voted up or down over there can chime in here?

@helgee
Copy link
Contributor

helgee commented Dec 20, 2017

I concur with all arguments made in favor of the rename in the original issue and I want to add that Void is a very jargony term in my opinion. It is an uncommon word and many non-native speakers will encounter it the first time in the context of programming.

Calling it Nothing probably saves them a trip to the dictionary if they are learning programming with Julia and thus lowers the barrier of entry.

@nalimilan
Copy link
Member

I think Nothing particularly improves clarity in docstrings where ::Union{T, Void} parameters and return values don't currently evoke the object nothing at all. The consistency with Missing is also really appealing.

@rfourquet
Copy link
Member

I like terseness, so it's hard for me to support officially this rename, considering this evolution in length:

  • Nullable{Int}
  • Union{Int,Void}
  • Union{Int,Nothing}

But if I'm honest, I must admit to secretely hope Nothing will win, because it just feels right. Void by conflating two notions, is inconsistent in naming with both nothing and C's void. Nothing plus the Cvoid alias seems the least surprising on both fronts. And maybe we will have something like a Maybe{Int} = Union{Int,Nothing} type anyway for terseness :)

@JeffBezanson
Copy link
Sponsor Member

Ok, I'm not really set against this. The arguments for it are pretty reasonable.

We should certainly have a shorter way to write Union{T,Nothing}.

@StefanKarpinski
Copy link
Sponsor Member Author

Ready to go when CI passes.

@StefanKarpinski
Copy link
Sponsor Member Author

MacOS timeout; everything else has passed (again).

@ararslan
Copy link
Member

Perhaps people who voted up or down over there can chime in here?

For whatever it's worth, I was one of the few dissenters, and I admit that Cvoid in ccall seems pretty nice. I actually dislike the trend of a singleton value thing having type Thing (and I rather like the name Void), which is mostly why I didn't like the proposal, but if we have a shorter way to write Union{T, Nothing} then that solves a significant portion of that concern for me.

@Sacha0
Copy link
Member

Sacha0 commented Dec 20, 2017

Perhaps people who voted up or down over there can chime in here?

Crossposting the relevant bit I posted in support:

The relationship between nothing and Void confused me when I came to Julia, and these changes completely eliminate that source of confusion. I find the Ptr{Void} -> Ptr{Cvoid} changes beautifully clarifying as well. ❤️!

git ls-files base doc examples src stdlib test | xargs perl -i -ple '/\b(ccall|cglobal|cfunction)\b/ && s/\bVoid\b/Cvoid/g'
git ls-files base doc examples src stdlib test | xargs perl -i -ple 's/\bPtr\{Void\}/Ptr{Cvoid}/g'
git ls-files base doc examples src stdlib test | xargs perl -i -ple 's/\Ref\{Void\}/Ref{Cvoid}/g'
perl -i -ple 's/\bVoid\b/Cvoid/g' base/atomics.jl base/libgit2/status.jl base/random/dSFMT.jl doc/src/manual/calling-c-and-fortran-code.md test/llvmcall.jl test/threads.jl
git ls-files base doc examples src stdlib test | xargs perl -i -ple 's/\bVoid\b/Nothing/g'
@quinnj
Copy link
Member

quinnj commented Dec 21, 2017

I'd be in favor of making T? desugar to Union{T, Nothing}. I've come to think that this definition will be more used/common than a previously suggested idea of having it desugar to Union{T, Missing}. Not something we need to rush into though; we still need some time for all the Union improvements to ripple through the ecosystem.

@StefanKarpinski
Copy link
Sponsor Member Author

StefanKarpinski commented Dec 21, 2017

Let's see where there's more pain... Feel pain, apply syntax?

@vchuravy
Copy link
Sponsor Member

FemtoCleaner is going to have it's work cut out for it :P

@StefanKarpinski
Copy link
Sponsor Member Author

Eh, this is a dead easy one to automate (as proved by the PR itself).

@ararslan
Copy link
Member

It's also now available in Compat.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:deprecation This change introduces or involves a deprecation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants