The FLS does not define what an "uninhabited type" is, and it should. I propose we insert the following rules between 4.1:1 and 4.1:2:
An :t:inhabited type is a :t:type with :t:[constructor]s and :t:[value]s.
An :t:uninhabited type is a :t:type without :t:[constructor]s and :t:[value]s.
The FLS also does not define what a "constructor" is, and it should. I propose we insert a new 6.1.3 Constructor Expressions subsection, with the following singular legality rule:
A :t:constructor is an :t:array expression, a :t:struct expression, or a :t:tuple expression.
(I probably missed an expression here...)
Needless to say, all these rules will need corresponding entries in the Glossary.
Give the above, I propose the following changes:
:dp:fls_Fs12dmznjsMf
Matching against an :t:enum variant of an :t:enum with more than one :t:[enum variant]s :t:captures <capturing> the :t:place by :t:immutable borrow as the :t:discriminant is read.
:dp:fls_7EXHdE2eOVek
Matching against an :t:enum variant of an :t:enum with one :t:enum variant does not :t:capture <capturing> the :t:place as the :t:discriminant is not read, unless the :t:enum is subject to :t:attribute non_exhaustive, in which case the :t:place is captured by :t:immutable borrow.
I do not understand what the type.closure.capture.precision.discriminants.uninhabited-variants Reference rule is trying to say. Is it something along the lines of "if an enum type has at least one inhabited variant, and possibly multiple uninhabited variants, then the discriminant is still read, thus capturing takes place"?
This comment is still relevant.
Originally posted by @kirtchev-adacore in #698 (comment)
The FLS does not define what an "uninhabited type" is, and it should. I propose we insert the following rules between 4.1:1 and 4.1:2:
An :t:
inhabited typeis a :t:typewith :t:[constructor]sand :t:[value]s.An :t:
uninhabited typeis a :t:typewithout :t:[constructor]sand :t:[value]s.The FLS also does not define what a "constructor" is, and it should. I propose we insert a new 6.1.3 Constructor Expressions subsection, with the following singular legality rule:
A :t:
constructoris an :t:array expression, a :t:struct expression, or a :t:tuple expression.(I probably missed an expression here...)
Needless to say, all these rules will need corresponding entries in the Glossary.
Give the above, I propose the following changes:
:dp:
fls_Fs12dmznjsMfMatching against an :t:
enum variantof an :t:enumwith more than one :t:[enum variant]s:t:captures <capturing>the :t:placeby :t:immutable borrowas the :t:discriminantis read.:dp:
fls_7EXHdE2eOVekMatching against an :t:
enum variantof an :t:enumwith one :t:enum variantdoes not :t:capture <capturing>the :t:placeas the :t:discriminantis not read, unless the :t:enumis subject to :t:attributenon_exhaustive, in which case the :t:placeis captured by :t:immutable borrow.I do not understand what the
type.closure.capture.precision.discriminants.uninhabited-variantsReference rule is trying to say. Is it something along the lines of "if an enum type has at least one inhabited variant, and possibly multiple uninhabited variants, then the discriminant is still read, thus capturing takes place"?This comment is still relevant.
Originally posted by @kirtchev-adacore in #698 (comment)