Date: Sun, 11 Sep 2022 20:31:11 -0400
On Sun, Sep 11, 2022 at 7:31 PM Zopolis0 via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Got it, thanks. I've adjusted the draft to reflect this.
>
> In regards to the motivation and scope, I am also working on that, but this draft is only for getting your feedback on the modifications to the wording of the standard changes and similar.
There's two problems with that. The first is that looking at the
wording is unhelpful if it isn't clear what the feature is supposed to
actually *do*. Standard wording is like programming; you can't
effectively write a program to solve a problem if you can't even
explain the problem in a normal, human language. And you certainly
cannot debug someone else's program if they haven't explained what the
program is supposed to accomplish. The same goes here: until it's
clear what the wording is meant to *do*, having wording is just not
helpful.
Second, wording is secondary in the initial analysis. Most proposals
don't have standard wording in their first version, as the purpose of
that version is to establish that the feature is desired and the
proposed shape of the feature is a good one. Similar to programming,
it's useless to get into the details of debugging a program if you
have yet to determine if the program actually does something that you
want to do.
Carts and horses work best in the traditional order.
As to the wording itself, it's still very much in the domain of "you
know what I mean, right?" This is the totality of your "wording":
> A module-declaration with a namespace-name has behaviour equal to a module containing a namespace-definition with a namespace-body enclosing all exported functions.
Standard wording needs to be *precise* and *specific*; this lacks both
precision and specificity. For example, modules don't "contain"
things; declarations and definitions reside in the purview of a
module. Also, modules don't export "functions"; they export *names*.
Do you really intend for this feature to only apply to functions?
How does this relate to other module units that comprise that module?
Like, if you have one module unit with a "namespace-definition" and
another unit within the same module without that definition, or with a
*different* "namespace-definition", how is that supposed to work?
What happens if you put this on a module implementation unit? After
all, implementation units cannot export things. So do names exist in
this namespace or not? If an interface unit has a
"namespace-definition" and exports some name, does that mean that an
implementation unit that defines it needs to explicitly use the
namespace when defining it?
<std-proposals_at_[hidden]> wrote:
>
> Got it, thanks. I've adjusted the draft to reflect this.
>
> In regards to the motivation and scope, I am also working on that, but this draft is only for getting your feedback on the modifications to the wording of the standard changes and similar.
There's two problems with that. The first is that looking at the
wording is unhelpful if it isn't clear what the feature is supposed to
actually *do*. Standard wording is like programming; you can't
effectively write a program to solve a problem if you can't even
explain the problem in a normal, human language. And you certainly
cannot debug someone else's program if they haven't explained what the
program is supposed to accomplish. The same goes here: until it's
clear what the wording is meant to *do*, having wording is just not
helpful.
Second, wording is secondary in the initial analysis. Most proposals
don't have standard wording in their first version, as the purpose of
that version is to establish that the feature is desired and the
proposed shape of the feature is a good one. Similar to programming,
it's useless to get into the details of debugging a program if you
have yet to determine if the program actually does something that you
want to do.
Carts and horses work best in the traditional order.
As to the wording itself, it's still very much in the domain of "you
know what I mean, right?" This is the totality of your "wording":
> A module-declaration with a namespace-name has behaviour equal to a module containing a namespace-definition with a namespace-body enclosing all exported functions.
Standard wording needs to be *precise* and *specific*; this lacks both
precision and specificity. For example, modules don't "contain"
things; declarations and definitions reside in the purview of a
module. Also, modules don't export "functions"; they export *names*.
Do you really intend for this feature to only apply to functions?
How does this relate to other module units that comprise that module?
Like, if you have one module unit with a "namespace-definition" and
another unit within the same module without that definition, or with a
*different* "namespace-definition", how is that supposed to work?
What happens if you put this on a module implementation unit? After
all, implementation units cannot export things. So do names exist in
this namespace or not? If an interface unit has a
"namespace-definition" and exports some name, does that mean that an
implementation unit that defines it needs to explicitly use the
namespace when defining it?
Received on 2022-09-12 00:32:01