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

Docs of construction undef arrays with missing #31091

Merged
merged 4 commits into from
Oct 30, 2020
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions doc/src/manual/missing.md
Original file line number Diff line number Diff line change
Expand Up @@ -254,6 +254,14 @@ julia> Array{Union{Missing, String}}(missing, 2, 3)
missing missing missing
```

!!! note
Currently for `T` that is bits type (`isbitstype(T)` returns `true`),
`Array{Union{Missing, T}}(undef, dims)` creates an array filled with
missing values. Also calling `similar` to create an unitialized array that
has element type of the form `Union{Missing, T}` creates an array filled with
`missing` if `T` is bits type. This behavior is an implementation detail
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Implementation detail that may change in the future" might be a bit strong, as it makes it sound like the public API cannot be relied on. Maybe just recommend using Array{Union{Missing, T}}(missing, dims), noting that it works for all types? Maybe also remove the leading "currently".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it is strong, but from the discussion I understood that we want to be discouraging. The question is if in e.g. Julia 1.7 we will guarantee this behavior (I know we rely on it internally, and the probability that this will change is minimal, but theoretically it is possible). In general - I understand that this is only the current behavior but it is not a part of a public API.

Actually, I have written this PR is exactly to clarify: do we want to make it a public API or just describe the current behavior and warn users that this is not a part of public API?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, that's part of the public API (anyway, any behavior that is stable like this will de facto end up as being part of the API since lots of code will rely on it). We can mark this for triage to make sure that's the case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK - can you please mark it?

any behavior that is stable like this will de facto end up as being part of the API since lots of code will rely on it

Yes- but I would prefer an explicit decision 😄.

Copy link
Member

@JeffBezanson JeffBezanson Mar 7, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you have Union{SingletonType, NonSingletonType} you are guaranteed to get the singleton type (e.g. Missing), and that won't change. For other combinations it's less predictable.

that may change in the future and should not be relied upon.

bkamins marked this conversation as resolved.
Show resolved Hide resolved
An array allowing for `missing` values but which does not contain any such value
can be converted back to an array which does not allow for missing values using
[`convert`](@ref). If the array contains `missing` values, a `MethodError` is thrown
Expand Down