rename Void => Nothing with alias Cvoid = Nothing #25082
Comments
StefanKarpinski
changed the title
Void => Nothing with const Cvoid = Nothing
|
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 |
|
Sure, I suppose I could reopen. It's just a lot of churn... |
|
Crossposting my comment in #25097:
|
|
I've also had this dream for a while: convert(::Type{Void}, x) = nothing
function doesnt_return_anything(x, y)::Void
something!(x, y)
endwhich would be possible if |
|
You can already do the above by defining: convert(::Type{Void}, x) = nothing
function doesnt_return_anything(x, y)::Void
something!(x, y)
endOf course, the danger here is that with that convert definition this would silently work: Void[1, 2, 3]and produce an array of three |
|
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 |
|
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 |
|
The inconsistency of |
FWIW, I was against renaming |
|
@TotalVerb: those languages also don't have a value of that type. The trouble is that we have a value of type |
|
@StefanKarpinski It's true of C/C++/C#/D/Java where "void" is a pseudo-type at best, but Swift does have a value |
|
Sure, the notion of having the empty tuple represent |
|
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 |
|
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). |
* Try to fix precompile issues for Julia 1.0 * Try to fix some static analysis test cases * Empty `Tuple` method dispatch See documentation on `Vararg` * Fix handling of `Vector` `Vector` has no types ⇒ `length(T.types) == 0` * Remove `try` without `catch` Why was it there to begin with? * basic.jl runs ok Added a heuristic on `lintpkg` to distinguish a package path from a package name. Compat `renamed is_windows`. * Re-write and documentation of `_lintstr` It was *REALLY* hard to understand the intent of the function. The code now is still verbose, but each _code block_ has its specific purpose. Before this we had several stateful variables and conditions that may or may not be triggered * Adjust versions No going back * Using Pkg * `isnull(…)` → `… == nothing` * Remove more `isnull`s and helper function `BROADCAST` * `contains` → `occursin` * Minor code update * `isbits` applies to objects, `isbitstype` to types `t` was supposed to be a type, not an object * Break expression from-string producer code * Use `let …` statements for several reasons ● It's visually easy to distinguish between two different test cases ● Ensures that global state will not change between tests * Colon detection in expression is bad. At least now I know how to fix it * Correctly detect a `:` * Break `guesstype` into multi-dispatch code. This will make testing much easier. Inspired on https://pixorblog.wordpress.com/2018/02/23/julia-dispatch-enum-vs-type-comparison/ (or https://www.juliabloggers.com/julia-dispatching-enum-versus-type/ ) * Fix `guesstype` tests * Remove more `get(…)` calls from version<07's nullables * `contains` → `occursin` * `@lintpragma` seems to be parsed differently now * sed -i s/contains/occursin/g *.jl * forgot that `occursin` has needle as 1st argument 😒 * `--compilecache=no` → `--compiled-modules=no` Per #256 (comment) * Remove `Test` as it belongs to std lib * Simple updates around `get(…)` and `isnull(…)` * Remove `occursin(…)` as they only clog testing now They were meant to test the error being popped, but this was before we had codes for errors. * Base.var → Statistics.var in v1.0 Also, cosmetics * Using another `Base.+` instead of `Base.var` Friendly reminder that Base.var → Statistics.var in v1.0 * Remove `occursin`s * Reformat dict tests * Looks like this test is no longer broken * `Void` → `Cvoid` See JuliaLang/julia#25082 for more context * Remove `occursin` (legacy testing before using codes) * Remove `occursin` * Forward `isknownerror` arguments from `infertype` * Chasing `shadowed variable` problem This error is the root of many tests failing * Drop versions prior to v1.0 * `… ≠ nothing` → `… !== nothing` #256 (comment) * Fix parsing Lines were being parsed _regardless_ of whether they were parsed before. Now the expression _and_ expression offset is being reported to keep track and omit lines already parsed * Mark TODO * Line iterator * Must handle (SubString) indices and not Strings We have to track offsets, so we need indices to the original string. It surprises me that `split(…)` does not return _or_ handle an iterator (forced Array output) * Rewrite test * Offset lines and most of expression iterator Re-wrote `each_line_iterator` so we can actually use it as iterator (with `iterate(…)`) * Inline functions, use offsets as lines * Iterators are hard * Redid the API to have line's offsets The code is made to report expression and line offsets, but I wrapped around those iterators to provide a "just expression" API * Try to replace previous parsing (doesn't work) * Missing try-catch Do mind that pre-compile forced `lintstr` seems to be reporting errors * delete legacy file
This was discussed previously a few times. The
Voidname only really makes sense in the context of interop with C, for which the nameCvoidis better. We have a pretty well-established convention thatnameis an element of typeNamesonothing :: Voidis a bit of a surprising gotcha. Way back when, this type was calledNothingbut it was deemed that we had too many kinds of nothingness, but we're really jumped the shark on that at this point.The text was updated successfully, but these errors were encountered: