[namespace.udecl] tweak the example in para 17 so that the comment is… #726

faisalv · 2016-05-17T04:02:03Z

… clear as to the reason for the ambiguity

the current comment could be interpreted as suggesting that the result of member-name-lookup (i.e. the declaration-set of S(x,D)) is ambiguous, which is certainly not the case -- the reason for the ambiguity is specified in [expr.ref]/5 -- and hopefully better reflected in the new comment.
add some additional examples that highlight the nuances of how the wording rejects or resolves certain member ambiguity.

… clear as to the reason for the ambiguity - the current comment could be interpreted as suggesting that the result of member-name-lookup (i.e. the declaration-set of S(x,D)) is ambiguous, which is certainly not the case -- the reason for the ambiguity is specified in [expr.ref]/5 -- and hopefully better reflected in the new comment. - add some additional examples that highlight the nuances of how the wording rejects or resolves certain member ambiguity.

tkoeppe · 2016-05-31T11:05:31Z

@faisalv: Can you please attach a diffpdf screenshot?

tkoeppe · 2016-06-08T14:11:30Z

@faisalv: Ping.

tkoeppe · 2016-06-08T22:33:22Z

source/declarations.tex

-int f(D* d) {
-  return d->x();    // ambiguous: \tcode{B::x} or \tcode{C::x}
+void f(D* d) {
+   d->x();       // ambiguous: \tcode{x}'s direct parent \tcode{A} is an ambiguous base of the naming class \tcode{D}


We never use the word "parent" in the context of classes. (We only use it in the context of threads and directories.) "Parent-child" is a terrible metaphor for class inheritance (children aren't parents). A better metaphor is "base-derived".

agreed - that parent sinifies the container of the declaration - so in
struct A { void f(); }; - regardless of how member lookup finds 'f' in
whichever hierarchy - the direct parent would be 'A'. Should I use direct
containing class?

Faisal Vali

On Wed, Jun 8, 2016 at 5:33 PM, Thomas Köppe notifications@github.com
wrote:

In source/declarations.tex
#726 (comment):

@@ -2935,8 +2935,12 @@
using C::x;
int x(double);
};
-int f(D* d) {

return d->x(); // ambiguous: \tcode{B::x} or \tcode{C::x}
+void f(D* d) {

d->x(); // ambiguous: \tcode{x}'s direct parent \tcode{A} is an ambiguous base of the naming class \tcode{D}

We never use the word "parent" in the context of classes. (We only use it
in the context of threads and directories.) "Parent-child" is a terrible
metaphor for class inheritance. A better metaphor is "base-derived".

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cplusplus/draft/pull/726/files/b79aef1dd96dd35e71094a5453967c5b74cf8646#r66352769,
or mute the thread
https://github.com/notifications/unsubscribe/AAxzPhiSgZHCtSD45VUKIW6EdEtj21rWks5qJ0M2gaJpZM4If6p6
.

Hmm - what about x's declaring class 'A' - i think i like prefer that in many ways

I'm not really sure. Technically correct terminology would be good, but brevity is also good.

@zygoloid, @villevoutilainen: Wording masters, any suggestions on improving this example code?

the class \tcode{A} where \tcode{x} is declared is an ambiguous base of the naming class \tcode{D} ?

Sounds good to me.

Thanks for the feedback. I made some changes. Let me know if you folks think this is better or worse or too much? Also do you still need a diffpdf (if so, if you could point me to any resources that show a non-cumbersome way to do it in windows would certainly be appreciated)?

Hmm - still trying to figure these comment threads out - so apologies if this is double spam but here is a snapshot to give you a visual:

The explanation and local terms are too much for my tastes, and I think they detract from the example as they're not directly linked to the terminology in the normative wording.

Fair enough - I'm not entirely unsympathetic to that POV. I might get motivated to re-style it at a future date - but if anyone sees any value in the general idea, feel free to take a crack at it. Thanks for the feedback.

faisalv · 2016-06-09T00:07:19Z

just seeing this - never done it before - will look into it - thanks!

Faisal Vali

On Tue, May 31, 2016 at 6:05 AM, Thomas Köppe notifications@github.com
wrote:

@faisalv https://github.com/faisalv: Can you please attach a diffpdf
screenshot?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#726 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAxzPlDkVm02tVNJh4odnfxMqJcIROK7ks5qHBYDgaJpZM4If6p6
.

faisalv · 2016-06-10T01:44:53Z

OK - I added a pdf preview - does this help?

…ted member lookup ambiguities

… clear as to the reason for the ambiguity - the current comment could be interpreted as suggesting that the result of member-name-lookup (i.e. the declaration-set of S(x,D)) is ambiguous, which is certainly not the case -- the reason for the ambiguity is specified in [expr.ref]/5 -- and hopefully better reflected in the new comment. - add some additional examples that highlight the nuances of how the wording rejects or resolves certain member ambiguity. - alter the Note comment so that it is clear that using-declarations can resolve certain inherited lookup ambiguities, and include an example to reflect that.

…/faisalv/draft into fv-adjust-ambiguous-base-example

faisalv · 2016-06-10T02:50:56Z

I tried to rebase and squash commits - hopefully this worked. I also amended the note and added an example to show how using-declarations can indeed be used to disambiguate inherited lookup ambiguities.

This is what the preview looks like:

tkoeppe · 2016-06-10T08:39:42Z

Thanks a lot for making the screenshot! That's really nice. With something that is difficult to lay out, it's always nice to see not just the source but also how it turns out.

diffpdf is a tool that compares two PDFs visually; occasionally, a screenshot of the diffpdf output can be nice to see whether some change is an improvement. But for the present purpose, my main concern is the layout of the example itself (not how it differs), so the screenshot you made is perfect.

tkoeppe reviewed Jun 8, 2016
View reviewed changes

Tune example based on feedback

9a726d7

faisalv added 3 commits June 9, 2016 21:25

Add an example that shows how using-declarations can help with inheri…

1591c71

…ted member lookup ambiguities

Merge branch 'fv-adjust-ambiguous-base-example' of https://github.com…

7384aad

…/faisalv/draft into fv-adjust-ambiguous-base-example

faisalv closed this Jun 11, 2016

faisalv deleted the fv-adjust-ambiguous-base-example branch June 11, 2016 14:47

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[namespace.udecl] tweak the example in para 17 so that the comment is… #726

[namespace.udecl] tweak the example in para 17 so that the comment is… #726

faisalv commented May 17, 2016

tkoeppe commented May 31, 2016 •

edited

tkoeppe commented Jun 8, 2016

tkoeppe Jun 8, 2016 •

edited

faisalv Jun 9, 2016

faisalv Jun 9, 2016

tkoeppe Jun 9, 2016

villevoutilainen Jun 9, 2016

villevoutilainen Jun 9, 2016

faisalv Jun 10, 2016

faisalv Jun 10, 2016

zygoloid Jun 10, 2016

faisalv Jun 10, 2016

faisalv commented Jun 9, 2016

faisalv commented Jun 10, 2016

faisalv commented Jun 10, 2016

tkoeppe commented Jun 10, 2016 •

edited

[namespace.udecl] tweak the example in para 17 so that the comment is… #726

[namespace.udecl] tweak the example in para 17 so that the comment is… #726

Conversation

faisalv commented May 17, 2016

tkoeppe commented May 31, 2016 • edited

tkoeppe commented Jun 8, 2016

tkoeppe Jun 8, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

faisalv commented Jun 9, 2016

faisalv commented Jun 10, 2016

faisalv commented Jun 10, 2016

tkoeppe commented Jun 10, 2016 • edited

tkoeppe commented May 31, 2016 •

edited

tkoeppe Jun 8, 2016 •

edited

tkoeppe commented Jun 10, 2016 •

edited