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

rename Void => Nothing with alias Cvoid = Nothing #25082

Closed
StefanKarpinski opened this issue Dec 14, 2017 · 20 comments
Closed

rename Void => Nothing with alias Cvoid = Nothing #25082

StefanKarpinski opened this issue Dec 14, 2017 · 20 comments
Milestone

Comments

@StefanKarpinski
Copy link
Sponsor Member

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.

@StefanKarpinski StefanKarpinski added the status:triage This should be discussed on a triage call label Dec 14, 2017
@StefanKarpinski StefanKarpinski changed the title rename Void => Nothing with const Cvoid = Nothing rename Void => Nothing with alias Cvoid = Nothing Dec 14, 2017
@StefanKarpinski
Copy link
Sponsor Member Author

StefanKarpinski commented Dec 14, 2017

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

@StefanKarpinski StefanKarpinski removed the status:triage This should be discussed on a triage call label Dec 14, 2017
@StefanKarpinski StefanKarpinski added this to the 1.0 milestone Dec 14, 2017
@StefanKarpinski
Copy link
Sponsor Member Author

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

@StefanKarpinski
Copy link
Sponsor Member Author

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

@nalimilan
Copy link
Member

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

@StefanKarpinski
Copy link
Sponsor Member Author

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

@Sacha0
Copy link
Member

Sacha0 commented Dec 15, 2017

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. ❤️!

@iamed2
Copy link
Contributor

iamed2 commented Dec 15, 2017

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 😄

@StefanKarpinski
Copy link
Sponsor Member Author

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.

@iamed2
Copy link
Contributor

iamed2 commented Dec 17, 2017

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.

@ararslan
Copy link
Member

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.

@TotalVerb
Copy link
Contributor

TotalVerb commented Dec 18, 2017

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.

@yurivish
Copy link
Contributor

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.

@StefanKarpinski
Copy link
Sponsor Member Author

StefanKarpinski commented Dec 18, 2017

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 😭

@StefanKarpinski
Copy link
Sponsor Member Author

@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.

@TotalVerb
Copy link
Contributor

@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.

@StefanKarpinski
Copy link
Sponsor Member Author

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).

@TotalVerb
Copy link
Contributor

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

@StefanKarpinski
Copy link
Sponsor Member Author

StefanKarpinski commented Dec 18, 2017

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).

@TotalVerb
Copy link
Contributor

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.

@nalimilan
Copy link
Member

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).

TotalVerb pushed a commit to tonyhffong/Lint.jl that referenced this issue Dec 21, 2018
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants