Recommend using Once::new() instead of ONCE_INIT?

std::sync::ONCE_INIT is in effect just an alias to std::sync::Once::new(), anyone using the former can use the latter since v1.2.0. I guess we can't outright deprecate ONCE_INIT given our backwards compatibility policy, but I would like to lint on its usage and at the very least call it out in the documentation ("use Once::new() instead").

This also opens the conversation around the larger problem of what to do with the parts of the API that would get superseded by new features, like const generics, or in this case const fns.

Can we just deprecate it?

std::sync::ONCE_INIT is in effect just an alias to std::sync::Once::new(), anyone using the former can use the latter since v1.2.0.

Why is sync::ONCE_INIT a problem?

Similarly, the initializers for the Atomic family of structs were deprecated in 1.34 and have a rustfix-able suggestion to use the new() function. For example, see ATOMIC_BOOL_INIT.

Why is sync::ONCE_INIT a problem?

"There should be only one way of doing it"™️ 🙂

I saw someone today get quite confused today as to why both existed in the first place, which required an explanation of rustc's backwards compatibility policy, const fn behavior, and rustc release schedules. I feel that we should have an aggressive funnel towards "the right way of doing things"™️ across the board, that includes linting against usages that are only kept because of historical reasons. At the very least I'd like to see the documentation updated so that it preempts the questions I got asked today 😁

"There should be only one way of doing it"™️ 🙂

/me Prepares plans to deprecate while true { ... } :)

In all seriousness, imo someone's confusion as to why both existed and "only one way to do it" is a rather weak justification for churn when the old way isn't harmful in any way.

At the very least I'd like to see the documentation updated so that it preempts the questions I got asked today 😁

Seems fine.

We deprecate things like ONCE_INIT 3 releases after their replacements (in this case Once::new specifically being a const fn) were added. I can't find in the release notes when that happened, but if someone tracks it down, it should be an easy PR!

@sfackler

@sfackler Once::new was stabilized all the way back in 1.2. Didn't find any reference to it in the release notes.

/me Prepares plans to deprecate while true { ... } :)

warning: denote infinite loops with `loop { ... }`
 --> src/main.rs:2:5
  |
2 |     while true {  } 
  |     ^^^^^^^^^^ help: use `loop`
  |
  = note: #[warn(while_true)] on by default

😬

Was it callable as a const fn in 1.2.0?

The const-ness was made stable in the same PR as for AtomicUsize::new: https://github.com/rust-lang/rust/pull/46287/files#diff-80754b8db8699947d7b2a43a9cc17dedL159

Rollup merge of rust-lang#61757 - sfackler:deprecate-once-init, r=ale…

Deprecate ONCE_INIT

Rollup merge of rust-lang#61757 - sfackler:deprecate-once-init, r=ale…

Navigation Menu

Repository navigation

Recommend using `Once::new()` instead of `ONCE_INIT`? #61746

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Recommend using Once::new() instead of ONCE_INIT? #61746

Description

Activity

tesuji commented on Jun 11, 2019

Centril commented on Jun 11, 2019

euclio commented on Jun 11, 2019

estebank commented on Jun 11, 2019

Centril commented on Jun 11, 2019

sfackler commented on Jun 11, 2019

estebank commented on Jun 12, 2019

estebank commented on Jun 12, 2019

sfackler commented on Jun 12, 2019

sfackler commented on Jun 12, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Recommend using `Once::new()` instead of `ONCE_INIT`? #61746