Skip to content

Update all references to my name #3153

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Jul 22, 2021
Merged

Update all references to my name #3153

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
2 changes: 1 addition & 1 deletion text/0089-loadable-lints.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ Allow users to load custom lints into `rustc`, similar to loadable syntax extens
There are many possibilities for user-defined static checking:

* Enforcing correct usage of Servo's [JS-managed pointers](https://github.com/mozilla/servo/blob/master/src/components/script/dom/bindings/js.rs)
* kballard's use case: checking that `rust-lua` functions which call `longjmp` never have destructors on stack variables
* lilyball's use case: checking that `rust-lua` functions which call `longjmp` never have destructors on stack variables
* Enforcing a company or project style guide
* Detecting common misuses of a library, e.g. expensive or non-idiomatic constructs
* In cryptographic code, annotating which variables contain secrets and then forbidding their use in variable-time operations or memory addressing
Expand Down
2 changes: 1 addition & 1 deletion text/0236-error-conventions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -228,7 +228,7 @@ comment for more detail.
There are numerous possible suffixes for a `Result`-producing variant:

* `_catch`, as proposed above. As
[@kballard points out](https://github.com/rust-lang/rfcs/pull/236#issuecomment-55344336),
[@lilyball points out](https://github.com/rust-lang/rfcs/pull/236#issuecomment-55344336),
this name connotes exception handling, which could be considered
misleading. However, since it effectively prevents further unwinding, catching
an exception may indeed be the right analogy.
Expand Down
6 changes: 3 additions & 3 deletions text/0240-unsafe-api-location.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,7 @@ and methods:

The unsafe methods and static functions for a given type should be placed in
their own `impl` block, at the end of the module defining the type; this will
ensure that they are grouped together in rustdoc. (Thanks @kballard for the
ensure that they are grouped together in rustdoc. (Thanks @lilyball for the
suggestion.)

# Drawbacks
Expand Down Expand Up @@ -125,7 +125,7 @@ There are a few alternatives:
them `unsafe`), and given that rustdoc could easily provide API grouping, it's
unclear exactly what the benefit is.

* ([Suggested by @kballard](https://github.com/rust-lang/rfcs/pull/240#issuecomment-55635468)):
* ([Suggested by @lilyball](https://github.com/rust-lang/rfcs/pull/240#issuecomment-55635468)):

> Use `raw` for functions that construct a value of the type without checking
> for one or more invariants.
Expand All @@ -140,7 +140,7 @@ There are a few alternatives:
some_string.slice_unchecked(start, end)
```

* Another suggestion by @kballard is to keep the basic structure of `raw`
* Another suggestion by @lilyball is to keep the basic structure of `raw`
submodules, but use associated types to improve the ergonomics. Details (and
discussions of pros/cons) are in
[this comment](https://github.com/rust-lang/rfcs/pull/240/files#r17572875).
Expand Down
12 changes: 6 additions & 6 deletions text/2497-if-let-chains.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1422,18 +1422,18 @@ Interestingly, the `EXPR is PAT` idea was floated in the original RFC 160 that
introduced `if let` expressions in the first place. There, the notion that an
operator named `is`, which introduces bindings, is confusing was brought up.

[kballard_1]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48515260
[kballard_2]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48551196
[lilyball_1]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48515260
[lilyball_2]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48551196
[liigo_1]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-49234092
[kballard_3]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-49242255
[lilyball_3]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-49242255

It was also mentioned by [@kballard][kballard_1] that it would be appropriate
It was also mentioned by [@lilyball][lilyball_1] that it would be appropriate
if, and only if, it was limited to pattern matching, but not introducing any
bindings. We make the same argument in this RFC. The issue of unintuitive
scopes was also mentioned [by @kballard][kballard_2] there.
scopes was also mentioned [by @lilyball][lilyball_2] there.

Even the idea of `if EXPR match PAT` was floated by [@liigo][liigo_1] at the
time but that idea was ultimately also rejected. [@kballard][kballard_3] opined
time but that idea was ultimately also rejected. [@lilyball][lilyball_3] opined
that using `match` as a binary operator would be *"very confusing"* but did not
elaborate further at the time.

Expand Down