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.
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 betweennothing
andVoid
confused me when I came to Julia, and these changes completely eliminate that source of confusion. Additionally, I find thePtr{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 nothing
s.
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).
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).