我读过 rfc 2005 是重复的操作。我说遇到参考模式
,我不是在谈论在第一次迭代中遇到参考模式,例如以下一个:
let x = &String;
// The binding mode is `move`, so x is of type `&String`
但是在某些情况下, banding模式
转移到> ref/ref/ref mut
在上一个非参考模式
迭代期间,然后遇到参考模式
。
我已经非常仔细地阅读了RFC,并且发现此句子 *默认绑定模式 *仅在与非参考模式匹配的引用时更改。
,这是指 code>参考模式将对匹配过程无能为力,但是有人告诉我参考模式
会将绑定模式重置回默认移动
(请参阅情况2)。
在两种情况下,“正确”的推论似乎相互冲突:
正确意味着推断的类型与编译器推断的类型相同,但是我不知道推断过程是否也正确,这就是我发布此问题的原因。
// case 1
let (a, b) = &(&String, &String); // a and b are of type &&String
// case 2
let (&a, &b) = &(&String, &String); // a and b are of type String
案例1的推断:
首先,我们匹配&(& string,& string)
反对(a,b)
和(a,b) )
是非参考模式
,因此我们Deref &(& string,string) and set bind> band> binding模式
从移动(默认一个)
到 ref
。然后,我们将(& string,string)与(a,b)
, ref
binding模式, a匹配
和 b
是类型&& string
。
为什么它停止在匹配(& string,& string)
对(a,b)
,我们不应该继续匹配&amp ; string
针对 a
和 b
分别?
如果我们继续,请匹配& string
与 a
, a 是 is 参考模式
,我们应该什么现在?
案例2的推断:
首先,我们匹配&(& string,& string)
反对(& a ,,&& b)
,()( & a,& b)
是非参考模式
,所以我们deref &(& string,& string)
and set 绑定模式
<代码> ref
。然后,我们匹配(&amp; string,&amp; string)
与(&amp; a,&amp; b)
,基本上是匹配&amp; string
反对&amp; a
,&amp; a
is 参考模式
,因此我们重置绑定模式回到移动
,制作类型
字符串
的。
矛盾:
在情况2中,当遇到参考模式时,我们要做的是将绑定模式重置为默认的移动
。但是,在情况1(如果我们那时我们不停下来,请保持匹配 string
针对 a
), a
也是参考模式
,如果我们仍然重置绑定模式移动,则A将具有类型&amp; string
而不是&amp;&amp;&amp; string
。
还有另一个问题,哪个是何时推断算法stop
?在情况1中,如果算法应该在此时停止,那么一切都会使人感官。
I have read the rfc 2005, knowing the process of manipulation is a repeated operation. And I say encounters reference pattern
, I am not talking about encountering reference pattern at the first iteration like the following one:
let x = &String;
// The binding mode is `move`, so x is of type `&String`
But some cases where binding mode
is shifted to ref/ref mut
during the previous non-reference pattern
iteration, and then encounters a reference pattern
.
I have read the rfc very carefully, and I found this sentence The *default binding mode* only changes when matching a reference with a non-reference pattern.
, does this mean reference pattern
will do nothing to the matching process, but someone told me reference pattern
will reset the binding mode back to the default move
(see case 2).
There are two cases where the "correct" inferences seem conflict with each other:
Correct means that the inferred type is the same as the one inferred by the compiler, but I don't know if the inferring process is also correct, which is the reason why I post this question.
// case 1
let (a, b) = &(&String, &String); // a and b are of type &&String
// case 2
let (&a, &b) = &(&String, &String); // a and b are of type String
Inference for case 1:
First, we are matching &(&String, &String)
against (a, b)
, and (a, b)
is non-reference pattern
, so we deref &(&String, &String)
and set binding mode
from move(default one)
to ref
. Then we are matching (&String, &String)
against (a, b)
, with ref
binding mode, a
and b
are of type &&String
.
Why did it stop at matching (&String, &String)
against (a, b)
, shouldn't we continue to match &String
against a
and b
respectively?
If we continue, matching &String
against a
, a
is reference pattern
, what should we do now?
Inference for case 2:
First, we are matching &(&String, &String)
against (&a, &b)
, (&a, &b)
is non-reference pattern
, so we deref &(&String, &String)
and set binding mode
to ref
. Then we match (&String, &String)
against (&a, &b)
, which is basically matching &String
against &a
, &a
is reference pattern
, so we reset binding mode back to move
, making a
of type String
.
Contradiction:
In case 2, when encounters reference pattern, what we do is to reset binding mode to the default move
. However in case 1(if we didn't stop at that point, keeping matching &String
against a
), a
is also reference pattern
, if we still reset binding mode to move, then a will have type &String
instead of &&String
.
And there is another question, which is when should this inferring algorithm stop
? In case 1, if the algorithm should stop at that point, then everything makes senses.
发布评论
评论(1)
似乎我找到了答案。有几件事要澄清:
匹配人体工程学
仅涵盖了我们与非参考模式匹配的情况
与参考
,所以这个问题的标题是错误的,匹配人体工程学
当相遇参考模式
时,无能为力。的算法匹配人体工程学
只是:默认绑定模式
是匹配符合符合人体工程学
的概念,但这不是独家对于匹配符合人体工程学的情况
,它已集成到整个生锈匹配系统中。参考模式的概念
可能会令人困惑。在rfc
中:在Rust Reference中,它只是模式以
&amp;/&amp; mut
。开始
匹配是一个递归过程,对于本递归中的每个过程,有几种情况,取决于模式我们正在遇到,其中包括
匹配人体工程学
案例。实际上在两种情况下,我们将更改DBD,一个是与
非参考模式
与参考
匹配,而另一个则是匹配的&amp; [ MUT] PAT
针对参考
。ref
或ref mut
移动
匹配算法
>对于案例1和2
第一个过程:我们正在匹配
(a,b)
与&amp;(&amp; string,string)
匹配,该 都进入案例3(任何另一种破坏性模式)。&amp;(&amp; string,&amp; string)
是&amp; t
,因此请deref itf it and默认绑定模式
to参考
。第二个过程:我们与
(a,b)匹配
与(&amp; string,string,string)
,这是基本上与a
相匹配的代码>&amp; string 。a
是标识符模式,它进入案例1。我们没有明确的ref/ref/ref mut
和默认绑定模式
isref
,因此,通过不变的参考,制作a
的类型&amp; amp; string
。所有模式都是匹配的,递归结束了。
第一个过程:我们匹配
(&amp; a,&amp; b)
fite&amp;(&amp; string,&amp; string)
,该进入案例3。derefand deref and and SET默认绑定模式
toref
第二个过程:我们匹配
(&amp; a,&amp; b)
fiter(&amp; string)
,&amp; string),基本上与&amp; a
与&amp; string
匹配。&amp; string
是参考模式
,因此我们进入了案例2,并设置默认绑定模式
移动
,&amp; a =&amp; string
,因此A具有类型String
所有模式都匹配,递归结束了。
该算法可能不是那么准确,欢迎那些知道这些东西编辑此答案的人。
Seems that I have found the answer. There are several things to clarify:
match ergonomics
only covers the cases where we are matchingnon-reference pattern
againstreference
, so the title of this question is wrong,match ergonomics
does nothing when encountersreference pattern
. The algorithm ofmatch ergonomics
is just something like:default binding mode
is a concept introduced formatch ergonomics
, but this is not exclusive to the cases covered bymatch ergonomics
, it has been integrated into the whole rust matching system.The concept of
reference pattern
can be confusing. Inrfc
:While in rust reference, it is just pattern beginning with
&/&mut
.Matching is a recursive process, for every procedure in this recursion, there are several cases depending what pattern we are encountering, which include the
match ergonomics
cases.There are actually two situations where we will change the DBD, one is matching
non-reference pattern
againstreference
, and the other is matching&[mut] pat
againstreference
.ref
orref mut
move
Matching algorithm
Inference for case 1 and 2
First procedure: we are matching
(a, b)
against&(&String, &String)
, which goes into case 3(any other kind of destructuring pattern).&(&String, &String)
is a&T
, so deref it and setdefault binding mode
toref
.Second procedure: we are matching
(a, b)
against(&String, &String)
, which is basicially matchinga
against&String
.a
is a identifier pattern, which goes into case 1. We don't have explicitref/ref mut
anddefault binding mode
isref
, so bind by immutable ref, makinga
of type&&String
.All the patterns are matched, recursion is over.
First procedure: we are matching
(&a, &b)
against&(&String, &String)
, which goes into case 3. Deref and setdefault binding mode
toref
Second procedure: we are matching
(&a, &b)
against(&String, &String)
, which is basically matching&a
against&String
.&String
is areference pattern
, so we goes into case 2, and setdefault binding mode
tomove
,&a = &String
, so a has typeString
All the patterns are matched, recursion is over.
The algorithm may not be that accurate, welcome people who know this stuff to edit this answer.