resolve how to handle constants and default binding modes #44849

nikomatsakis · 2017-09-25T19:49:54Z

Another interesting question that @tschottdorf encountered when implementing default binding modes: What do we do with constants? The RFC specifies that we ought to treat a FOO binding that resolves to a constant as something which can skip through &T types -- however, that runs into trouble if the type of the constant itself is &str or &[T]. The current logic at least skips through all &T or &mut T types when it skips through any, but handling &str correctly would require skipping through "only the right number".

@tschottdorf implemented various rules but we should at minimum update the RFC to match.

The text was updated successfully, but these errors were encountered:

nikomatsakis · 2017-10-03T10:32:54Z

An example. Per the language in the RFC, constants of reference type will not "autoderef", but that means that this example does not work, which seems unfortunate:

let s: &'static str = "abc";
match &s {
  "abc" => true,
  _ => panic!(),
};

@nikomatsakis

Stabilize match_default_bindings This includes a submodule update to rustfmt in order to allow a stable feature declaration. r? @nikomatsakis cc #42640 Many of the tests this PR touches are merely testing the current lack of desired future behavior around #44849 and #44848 (cc @tschottdorf). I noticed the bullets for those items were checked on the tracking issue-- I've unchecked them, as they don't appear to have been completed and I don't see any comments indicating that we don't want to pursue them further. Still, I think it's fine to stabilize the current behavior, as I think expanding it in the future should be backwards-compatible.

@nikomatsakis

Stabilize match_default_bindings This includes a submodule update to rustfmt in order to allow a stable feature declaration. r? @nikomatsakis cc #42640 Many of the tests this PR touches are merely testing the current lack of desired future behavior around #44849 and #44848 (cc @tschottdorf). I noticed the bullets for those items were checked on the tracking issue-- I've unchecked them, as they don't appear to have been completed and I don't see any comments indicating that we don't want to pursue them further. Still, I think it's fine to stabilize the current behavior, as I think expanding it in the future should be backwards-compatible.

`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns When `deref_patterns` is enabled, this allows string literal patterns to be used where `str` is expected and byte string literal patterns to be used where `[u8]` or `[u8; N]` is expected. This lets them be used in explicit `deref!("...")` patterns to match on `String`, `Box<str>`, `Vec<u8>`, `Box<[u8;N]>`, etc. (as well as to match on slices and arrays obtained through other means). Implementation-wise, this follows up on rust-lang#138992: similar to how byte string literals matching on `&[u8]` is implemented, this changes the type of the patterns as determined by HIR typeck, which informs const-to-pat on how to translate them to THIR (though strings needed a bit of extra work since we need references to call `<str as PartialEq>::eq` in the MIR lowering for string equality tests). This PR does not add support for implicit deref pattern syntax (e.g. `"..."` matching on `String`, as `string_deref_patterns` allows). I have that implemented locally, but I'm saving it for a follow-up PR[^1]. This also does not add support for using named or associated constants of type `&str` where `str` is expected (nor likewise with named byte string constants). It'd be possible to add that if there's an appetite for it, but I figure it's simplest to start with literals. This is gated by the `deref_patterns` feature since it's motivated by deref patterns. That said, its impact reaches outside of deref patterns; it may warrant a separate experiment and feature gate, particularly factoring in the follow-up[^1]. Even without deref patterns, I think there's probably motivation for these changes. The update to the unstable book added by this will conflict with rust-lang#140022, so they shouldn't be merged at the same time. Tracking issue for deref patterns: rust-lang#87121 r? `@oli-obk` cc `@Nadrieril` [^1]: The piece missing from this PR to support implicit deref pattern syntax is to allow string literal patterns to implicitly dereference their scrutinees before matching (see rust-lang#44849). As a consequence, it also makes examples like the one in that issue work (though it's still gated by `deref_patterns`). I can provide more information on how I've implemented it or open a draft if it'd help in reviewing this PR.

`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns When `deref_patterns` is enabled, this allows string literal patterns to be used where `str` is expected and byte string literal patterns to be used where `[u8]` or `[u8; N]` is expected. This lets them be used in explicit `deref!("...")` patterns to match on `String`, `Box<str>`, `Vec<u8>`, `Box<[u8;N]>`, etc. (as well as to match on slices and arrays obtained through other means). Implementation-wise, this follows up on rust-lang#138992: similar to how byte string literals matching on `&[u8]` is implemented, this changes the type of the patterns as determined by HIR typeck, which informs const-to-pat on how to translate them to THIR (though strings needed a bit of extra work since we need references to call `<str as PartialEq>::eq` in the MIR lowering for string equality tests). This PR does not add support for implicit deref pattern syntax (e.g. `"..."` matching on `String`, as `string_deref_patterns` allows). I have that implemented locally, but I'm saving it for a follow-up PR[^1]. This also does not add support for using named or associated constants of type `&str` where `str` is expected (nor likewise with named byte string constants). It'd be possible to add that if there's an appetite for it, but I figure it's simplest to start with literals. This is gated by the `deref_patterns` feature since it's motivated by deref patterns. That said, its impact reaches outside of deref patterns; it may warrant a separate experiment and feature gate, particularly factoring in the follow-up[^1]. Even without deref patterns, I think there's probably motivation for these changes. The update to the unstable book added by this will conflict with rust-lang#140022, so they shouldn't be merged at the same time. Tracking issue for deref patterns: rust-lang#87121 r? ``@oli-obk`` cc ``@Nadrieril`` [^1]: The piece missing from this PR to support implicit deref pattern syntax is to allow string literal patterns to implicitly dereference their scrutinees before matching (see rust-lang#44849). As a consequence, it also makes examples like the one in that issue work (though it's still gated by `deref_patterns`). I can provide more information on how I've implemented it or open a draft if it'd help in reviewing this PR.

Rollup merge of rust-lang#140028 - dianne:lit-deref-pats-p1, r=oli-obk `deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns When `deref_patterns` is enabled, this allows string literal patterns to be used where `str` is expected and byte string literal patterns to be used where `[u8]` or `[u8; N]` is expected. This lets them be used in explicit `deref!("...")` patterns to match on `String`, `Box<str>`, `Vec<u8>`, `Box<[u8;N]>`, etc. (as well as to match on slices and arrays obtained through other means). Implementation-wise, this follows up on rust-lang#138992: similar to how byte string literals matching on `&[u8]` is implemented, this changes the type of the patterns as determined by HIR typeck, which informs const-to-pat on how to translate them to THIR (though strings needed a bit of extra work since we need references to call `<str as PartialEq>::eq` in the MIR lowering for string equality tests). This PR does not add support for implicit deref pattern syntax (e.g. `"..."` matching on `String`, as `string_deref_patterns` allows). I have that implemented locally, but I'm saving it for a follow-up PR[^1]. This also does not add support for using named or associated constants of type `&str` where `str` is expected (nor likewise with named byte string constants). It'd be possible to add that if there's an appetite for it, but I figure it's simplest to start with literals. This is gated by the `deref_patterns` feature since it's motivated by deref patterns. That said, its impact reaches outside of deref patterns; it may warrant a separate experiment and feature gate, particularly factoring in the follow-up[^1]. Even without deref patterns, I think there's probably motivation for these changes. The update to the unstable book added by this will conflict with rust-lang#140022, so they shouldn't be merged at the same time. Tracking issue for deref patterns: rust-lang#87121 r? ``@oli-obk`` cc ``@Nadrieril`` [^1]: The piece missing from this PR to support implicit deref pattern syntax is to allow string literal patterns to implicitly dereference their scrutinees before matching (see rust-lang#44849). As a consequence, it also makes examples like the one in that issue work (though it's still gated by `deref_patterns`). I can provide more information on how I've implemented it or open a draft if it'd help in reviewing this PR.

nikomatsakis added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-compiler-middle labels Sep 25, 2017

nikomatsakis mentioned this issue Sep 25, 2017

tracking issue for default binding modes in match (RFC 2005, match_default_bindings) #42640

Closed

7 tasks

TimNN added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Sep 27, 2017

cramertj mentioned this issue Mar 26, 2018

Stabilize match_default_bindings #49394

Merged

jackh726 removed the WG-compiler-middle label Jan 29, 2022

dianne mentioned this issue Apr 19, 2025

deref_patterns: support string and byte string literals in explicit deref!("...") patterns #140028

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

resolve how to handle constants and default binding modes #44849

resolve how to handle constants and default binding modes #44849

nikomatsakis commented Sep 25, 2017

nikomatsakis commented Oct 3, 2017

resolve how to handle constants and default binding modes #44849

resolve how to handle constants and default binding modes #44849

Comments

nikomatsakis commented Sep 25, 2017

nikomatsakis commented Oct 3, 2017