Julia: rename Void => Nothing with alias Cvoid = Nothing

Created on 14 Dec 2017  路  20Comments  路  Source: JuliaLang/julia

This was discussed previously a few times. The Void name only really makes sense in the context of interop with C, for which the name Cvoid is better. We have a pretty well-established convention that name is an element of type Name so nothing :: Void is a bit of a surprising gotcha. Way back when, this type was called Nothing but it was deemed that we had too many kinds of nothingness, but we're really jumped the shark on that at this point.

Most helpful comment

I think we should discuss whether that's a good choice in absolute terms. The churn is really a secondary issue, and it's quite minor compared with all other breakage in 0.7 (Compat will handle it very nicely).

All 20 comments

I will take a look at this and see if it feels better or not. Milestoning just as a reminder.

Based on the PR sketching this out, I'm not sure if this churn is really worth it.

Since I'm the one who opened this and I don't care for it, I guess I'll just close this.

Hey, you've got +11 vs -1, so I think it's worth it (but after the PR removing Nullable is merged...).

Sure, I suppose I could reopen. It's just a lot of churn...

Crossposting my comment in #25097:

Much thanks for exploring this change concretely @StefanKarpinski! For what it's worth, having just looked over this branch I quite like it. The relationship between nothing and Void confused me when I came to Julia, and these changes completely eliminate that source of confusion. Additionally, I find the Ptr{Void} -> Ptr{Cvoid} changes beautifully clarifying as well. 鉂わ笍!

I've also had this dream for a while:

convert(::Type{Void}, x) = nothing

function doesnt_return_anything(x, y)::Void
    something!(x, y)
end

which would be possible if Void was freed up. Then Void could be a "void" that you put stuff in and never get out 馃槃

You can already do the above by defining:

convert(::Type{Void}, x) = nothing

function doesnt_return_anything(x, y)::Void
    something!(x, y)
end

Of course, the danger here is that with that convert definition this would silently work:

Void[1, 2, 3]

and produce an array of three nothings.

Exactly. I would not want it to be a type that people use often, to avoid causing unexpected behaviour. I wouldn't propose that now, as Void currently has other uses.

FWIW I agree that the churn isn't worth it, but clearly I'm in the minority as the sole dissenter by show of thumbs.

I also agree that the churn isn't worth it. The Wikipedia article lists, in addition to C, C++, C#, D and Java, also the newer language Swift as using the name "Void". By contrast no language uses Nothing as the name for this, as far as I can tell.

The inconsistency of nothing/Void with missing/Missing always confuses me. I don't mind either name, so if they were void/Void I'd be just as happy as nothing/Nothing, but having the type and instance be called different things seems pretty bad.

I also agree that the churn isn't worth it.

FWIW, I was against renaming Nothing to Void in the first place. This was very avoidable churn 馃槶

@TotalVerb: those languages also don't have a value of that type. The trouble is that we have a value of type Void called nothing. That's just straight up confusing. If the instance was called void it would be better, but that would be bad too since void is what all those languages call the type, not the (non-existent) instance of that type. So I still think having nothing :: Nothing is the best we can do and have Cvoid as an alias for use when interfacing with C, et al.

@StefanKarpinski It's true of C/C++/C#/D/Java where "void" is a pseudo-type at best, but Swift does have a value () of type Void.

Sure, the notion of having the empty tuple represent nothing was raised in that old thread I linked to and it was rejected since () is a perfectly valid value of interest and not an indicator of "nothing to see here" the way that nothing is (by definition).

Right but it is used as a nothing-to-see-here in Swift, so I am raising it as a point of prior art.

Sure, there's a lot of history to that choice from Lisp, but it's always struck me as fairly inappropriate. Lisp had the excuse that there's not really any other choice that makes sense (unless, of course, they defined there to be an opaque value for the purpose).

Nevertheless, I am not arguing for the replacement of nothing by () as in Swift, but just raising the point that Swift does take the type-alias Void for its "nothing"-like object (defined as, for example, what is returned by return with no object following), so the name is not without precedent.

I think we should discuss whether that's a good choice in absolute terms. The churn is really a secondary issue, and it's quite minor compared with all other breakage in 0.7 (Compat will handle it very nicely).

Was this page helpful?
0 / 5 - 0 ratings