Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2994363003:
Generalized void informal spec clarified in several locations. (Closed)
|
Created:
3 years, 4 months ago by eernst Modified:
3 years, 3 months ago Reviewers:
Lasse Reichstein Nielsen CC:
reviews_dartlang.org, floitsch Target Ref:
refs/heads/master Visibility:
Public. |
DescriptionGeneralized void informal spec clarified in several locations.
R=lrn@google.com
Committed: https://github.com/dart-lang/sdk/commit/839c3216085bb07a086b0389ca2dbed9ea2861f5
Patch Set 1 #
Total comments: 7
Patch Set 2 : Review response #Patch Set 3 : Updated "Updates" #
Total comments: 17
Patch Set 4 : Review response #Messages
Total messages: 9 (2 generated)
eernst@google.com changed reviewers: + lrn@google.com
lgtm https://codereview.chromium.org/2994363003/diff/1/docs/language/informal/gene... File docs/language/informal/generalized-void.md (right): https://codereview.chromium.org/2994363003/diff/1/docs/language/informal/gene... docs/language/informal/generalized-void.md:36: value of the corresponding expression evaluation is useless. Hence, there Maybe: "useless and unspecified" https://codereview.chromium.org/2994363003/diff/1/docs/language/informal/gene... docs/language/informal/generalized-void.md:179: type in a function type, the reified representation is equal (according to What does it mean to "occur as a parameter type" in a function type? I'd say "Function(void)", but there is nothing reified about that one, so I'm not sure what this is saying. https://codereview.chromium.org/2994363003/diff/1/docs/language/informal/gene... docs/language/informal/generalized-void.md:179: type in a function type, the reified representation is equal (according to Consider: equal -> equivalent We use "equivalent" below. https://codereview.chromium.org/2994363003/diff/1/docs/language/informal/gene... docs/language/informal/generalized-void.md:182: *It is encouraged for an implementation to use a reified representation for Wording, consider: "An implementation is encouraged to .." (Shorter and more direct, I'm trying to avoid using "it" too much myself :). https://codereview.chromium.org/2994363003/diff/1/docs/language/informal/gene... docs/language/informal/generalized-void.md:257: *That is, the type void is considered to be equivalent to the built-in Here we use "equivalent".
Review response: Critical paragraphs rewritten substantially. https://codereview.chromium.org/2994363003/diff/1/docs/language/informal/gene... File docs/language/informal/generalized-void.md (right): https://codereview.chromium.org/2994363003/diff/1/docs/language/informal/gene... docs/language/informal/generalized-void.md:36: value of the corresponding expression evaluation is useless. Hence, there On 2017/08/22 05:31:06, Lasse Reichstein Nielsen wrote: > Maybe: "useless and unspecified" Adjusted to 'meaningless'. https://codereview.chromium.org/2994363003/diff/1/docs/language/informal/gene... docs/language/informal/generalized-void.md:179: type in a function type, the reified representation is equal (according to On 2017/08/22 05:31:06, Lasse Reichstein Nielsen wrote: > Consider: equal -> equivalent > We use "equivalent" below. Done.
PTAL: The text was changed rather substantially.
lgtm https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... File docs/language/informal/generalized-void.md (right): https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:33: Note that it is not technically dangerous to use a value of type `void`, In my quixotic quest to abolish "it" (which you can ignore because it doesn't affect correctness), consider rewording to: Note that using a value of type `void` is not technically dangerous; doing so does not violate any language semantics contraints. I'm still concerned because values do not have the type void, so maybe: Note that using the value of an expression of type `void` is not technically dangerous; ... https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:35: semantics. By using the type `void`, developers just indicate that the Drop "just". It's a word that carries a lot of insinuation, and it rarely makes anything more precise. https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:47: The mechanisms helping developers to avoid using values of type `void` are values of type `void` -> values of expression of type `void` https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:51: in order to ensure that direct usage of a value of type `void` is a static values of type `void` -> ... you get the point. More of these below. https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:172: could be evaluated as an expression). It is therefore not necessary to The function type cannot actually be evaluated as an expression, but it can be used as a type argument and the corresponding type variable used as an expression. https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:173: have a reified representation of such a return type.* A reified representation of such a return type is therefore not necessary. (Maybe). https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:176: the reified representation at run time must be such that the type void and void -> `void` ? https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:200: void does not need to be reified at run time.* This is a specification, so is it or is it not reified? What does mirrors do? (IOW, don't let this stand by itself, complete it by saying ", and it isn't.") https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:308: `Object` plus a "static voidness flag"), but values of type void should be values of type void -> values with static type void (the values doesn't have the type void, but it might be the only statically know type for the value) Alternatively: values -> expressions.
Description was changed from ========== Generalized void informal spec clarified in several locations. ========== to ========== Generalized void informal spec clarified in several locations. R=lrn@google.com Committed: https://github.com/dart-lang/sdk/commit/839c3216085bb07a086b0389ca2dbed9ea2861f5 ==========
Message was sent while issue was closed.
Committed patchset #4 (id:60001) manually as 839c3216085bb07a086b0389ca2dbed9ea2861f5 (presubmit successful).
Message was sent while issue was closed.
Review response https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... File docs/language/informal/generalized-void.md (right): https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:33: Note that it is not technically dangerous to use a value of type `void`, On 2017/08/30 05:29:51, Lasse Reichstein Nielsen wrote: > In my quixotic quest to abolish "it" (which you can ignore because it doesn't > affect correctness), consider rewording to: > > Note that using a value of type `void` is not technically dangerous; doing so > does not violate any language semantics contraints. > > I'm still concerned because values do not have the type void, so maybe: > > Note that using the value of an expression of type `void` is not technically > dangerous; ... > Done. https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:35: semantics. By using the type `void`, developers just indicate that the On 2017/08/30 05:29:51, Lasse Reichstein Nielsen wrote: > Drop "just". It's a word that carries a lot of insinuation, and it rarely makes > anything more precise. Done. https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:47: The mechanisms helping developers to avoid using values of type `void` are On 2017/08/30 05:29:51, Lasse Reichstein Nielsen wrote: > values of type `void` -> values of expression of type `void` Done. https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:172: could be evaluated as an expression). It is therefore not necessary to On 2017/08/30 05:29:51, Lasse Reichstein Nielsen wrote: > The function type cannot actually be evaluated as an expression, but it can be > used as a type argument and the corresponding type variable used as an > expression. Right, or it could be defined in a non-parameterized typedef `F` which could be evaluated as an expression. Adjusted the text to focus on the type variable example that you gave. https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:173: have a reified representation of such a return type.* On 2017/08/30 05:29:51, Lasse Reichstein Nielsen wrote: > A reified representation of such a return type is therefore not necessary. > > (Maybe). Done. There goes another `it`. ;-) https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:176: the reified representation at run time must be such that the type void and On 2017/08/30 05:29:51, Lasse Reichstein Nielsen wrote: > void -> `void` > ? I actually have 21 occurrences of '`void`' and 64 occurrences of '[^`]\bvoid\b[^`]', 10-or-so of which are part of a source code snippet. So there are significantly more usages of a plain 'void' than '`void`' (hence, this one isn't a lone typo). The approach I've tried to maintain is that '`void`' is used when the context definitely requires that the token `void` occurs in the source code (or when it refers to a hypothetical example situation where it might as well occur, in order to keep the example simple), and otherwise a plain non-source 'void' is used. In particular, it is important to allow for the "semantic void" rather than the "syntactic void" in cases where we argue that it is a non-problem that we don't reify void, because the justification should work for "semantic void", not just syntactic. I've kept all the occurrences of the plain 'void' for now. https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:200: void does not need to be reified at run time.* On 2017/08/30 05:29:51, Lasse Reichstein Nielsen wrote: > This is a specification, so is it or is it not reified? > What does mirrors do? > > (IOW, don't let this stand by itself, complete it by saying ", and it isn't.") All this commentary stuff is a follow-up on 'There is no value which is the reified representation of the type void at run time.' in line 159, so in that sense it's clear. Still added 'and it isn't', though. https://codereview.chromium.org/2994363003/diff/40001/docs/language/informal/... docs/language/informal/generalized-void.md:308: `Object` plus a "static voidness flag"), but values of type void should be On 2017/08/30 05:29:51, Lasse Reichstein Nielsen wrote: > values of type void -> values with static type void > > (the values doesn't have the type void, but it might be the only statically know > type for the value) > Alternatively: values -> expressions. Done. |
