Howard Gardner wrote:
> Here's some code:
>
> template<typename T>
>    where LessThanComparable<T>
>      const T & min(const T & l, const T & r);

> The sql analogy is bad, because this alternative explanation is clearly
> awful:
>
> "The where clause works like it does in sql."

I guess I don't understand exactly where the SQL analogy breaks down.
Back in the beginning of this thread, you mentioned that it might be
turned around like this:

> It will lead a lot of people to: template is to where as select is to
> where. If you work real hard, you can probably make that analogy fit in
> some fuzzy way, and end up with false notions as a result.

I can't imagine that anyone would try to take the analogy that far. A
C++ programmer knows what a template is, even if s/he doesn't
understand all of the details (who does?), and is unlikely to confuse a
template with a SQL select statement. The power of analogies is that
they adapt to their context: if we then say "with concepts, the where
clause on a template is like the where clause on a select statement" to
a SQL-savvy C++ programmer, I'd expect her to imagine how WHERE
modifies a SELECT (it restricts the result set) and apply that notion
to templates (it restricts the allowed type parameters). On reading
Steve Hicks reply, I feel even better about the SQL analogy.

Could you perhaps enumerate the problems you see with the analogy?
Where does it actually break down, and would a SQL-savvy C++ programmer
(who knows what templates and select statements are, already) consider
taking the analogy that far?

> The syntax from the paper is:
>
> assert Is_Numeric<T>;
>
> assert is another new keyword. If the assert fails, it causes an
> immediate error. Hopefully, the diagnostic will indicate which part of
> the concept T fails to model.

The "assert" keyword is not used in the latest concepts proposal,
N2042. N2042 is the proposal that we're bringing to the C++ committee.
It is a bit different from earlier proposals, and probably worth a
re-read for those interested:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2042.pdf

> It will also help when writing templates, because it will help develop
> with developing archetypes.

Archetypes aren't necessary any more. Complete type-checking for
constrained templates catches all of the errors that archetypes could
catch (and more that archetypes would miss), with much-improved error
messages and less effort on the user's part.

> It led me to an actively harmful analogy.

I'm still grasping to understand how it can be harmful.

> You did better work, and so
> arrived at an analogy that is merely useless.

?

>  > But I hardly reckon my own experience much compared to the rest of the
>  > folks posting here (and I certainly couldn't make it through either of
>  > those technical articles),
>
> Meh, we're just programmers. Well, I am anyway.

It's extremely important for us to hear reactions to concepts from
*everyone*. I've been working on concepts in C++ for several years,
have written a significant fraction of the concepts proposals and led
the implementation of the only concept-enabled C++ compiler and its
Standard Library. Concepts, "where", and everything in those proposals
is second nature to me, which makes it very hard for me to step back
and evaluate the terminology objectively. If the SQL analogy is bad or
harmful, I need to know why (because someone *will* ask).

As for N1885-6, they were originally meant for a different audience
(academic researchers in programming languages). I expect N2042 will be
much easier reading. As the October C++ committee meeting in Portland
draws closer, we'll provide much more introductory material (tutorials,
presentations, etc.). We would *really* appreciate feedback from
everyone.

  Doug

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Douglas Gregor wrote:
> Where does it actually break down, and would a SQL-savvy C++ programmer
> (who knows what templates and select statements are, already) consider
> taking the analogy that far?
>

Which analogy? All of the ones that I have seen or imagined to date
break down instantly by utterly failing their purpose, which is to
simplify an explanation. So far, every explanation that I have seen that
  uses the sql context is more complex than the explanations that don't.

The point isn't that it is impossible to draw a plausible sql analogy,
but that it is impossible to draw a useful sql analogy.

Demonstrate it to yourself. Explain this code fragment:

template<typename T>
   where LessThanComparable<T>
     const T & min(const T & l, const T & r);

>> The syntax from the paper is:
>>
>> assert Is_Numeric<T>;
>>
>> assert is another new keyword. If the assert fails, it causes an
>> immediate error. Hopefully, the diagnostic will indicate which part of
>> the concept T fails to model.
>
> The "assert" keyword is not used in the latest concepts proposal,
> N2042. N2042 is the proposal that we're bringing to the C++ committee.
> It is a bit different from earlier proposals, and probably worth a
> re-read for those interested:
>
>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2042.pdf
>

Thanks.

>> It will also help when writing templates, because it will help develop
>> with developing archetypes.
>
> Archetypes aren't necessary any more.

I wonder about that.

Here's a solution to is_same_template< TYPE, TYPE >. Because the types
that I use it on in the example have archetypes, it also solves
is_same_template< CLASS_TEMPLATE, CLASS_TEMPLATE > for those types.

The archetypes effectively transform the problem from the class template
metaprogramming domain (where metafunction template parameters are class
templates) to the type metaprogramming domain (where metafunction
template parameters are types).

#include <cstddef>
#include <ostream>
using namespace std;

template< typename >
  struct
     arity1{};

struct
   arity1_archetype{};

template< typename, typename >
   struct
     arity2{};

struct
  arity2_archetype0{};

struct
  arity2_archetype1{};

template< typename, typename >
   struct
     is_same_template
     {
       static const bool value = false;
     };

template
<
   template< typename > class xT,
   typename x0,
   typename x1
 >
   struct
     is_same_template< xT< x0 >, xT< x1 > >
     {
       static const bool value = true;
     };

template
<
   template< typename, typename > class xT,
   typename x0,
   typename x1,
   typename x2,
   typename x3
 >
   struct
     is_same_template< xT< x0, x1 >, xT< x2, x3 > >
     {
       static const bool value = true;
     };

int
   main()
   {
     cout
       <<
         is_same_template
         <
           arity1< arity1_archetype >,
           arity1< int >
         >
         ::value
       <<
         endl;

     cout
       <<
         is_same_template
         <
           arity1< arity1_archetype >,
           arity2< int, int >
         >
         ::value
       <<
         endl;

     cout
       <<
         is_same_template
         <
           arity2< arity2_archetype0, arity2_archetype1 >,
           arity2< int, int >
         >
         ::value
       <<
         endl;

     cout
       <<
         is_same_template
         <
           arity2< arity2_archetype0, arity2_archetype1 >,
           arity1< int >
         >
         ::value
       <<
         endl;
   }

That solution is fine if I only want to use it on class templates for
which archetypes are dutifully maintained--for example, within my library.

I want to use it in on class templates that originate in application
code too, though, and I'm pretty sloppy about archetypes there. I solved
the problem directly in the class template domain. That solution doesn't
require the archetypes in order to work, but it is no beauty. It took
much MUCH longer to work out than the solution above did. Worse, the
interface to it is awkward.

is_same_template is the only class template domain metaprogramming that
I've needed so far, but it seems likely that I will want to program in
that domain again. I wonder if it will be easier to do in c++0x, and I
wonder if the results will be better.

>> Complete type-checking for
>> constrained templates catches all of the errors that archetypes could
>> catch (and more that archetypes would miss), with much-improved error
>> messages and less effort on the user's part.
>>

>> It led me to an actively harmful analogy.
>
> I'm still grasping to understand how it can be harmful.
>

I've been 30 years before the keyboard, man and boy. I've used SQL since
the mid 80's. I've used c++ since 1991. I've been using templates since
1995. I use enable_if routinely. If anyone was ready to understand what
"where" does with minimal explanation, it was me.

The explanation that I happened to see first left me to invent my own
sql analogy, and I botched the analogy so badly that I misunderstood the
feature. Specifically, I did not grasp the implication of a failed where
clause. I thought it was an error.

If the keyword were enable_if I would have understood it with no
explanation at all. If it were some random string of letters, then I'd
have gotten it right quick.

It's not, though.

Its a sql word.

OMG WHY?????

(Rhetorical ;)

>> You did better work, and so
>> arrived at an analogy that is merely useless.
>
> ?

It did not help him to understand the feature, which is the only thing
an analogy can do.

> As for N1885-6, they were originally meant for a different audience
> (academic researchers in programming languages). I expect N2042 will be
> much easier reading. As the October C++ committee meeting in Portland
> draws closer, we'll provide much more introductory material (tutorials,
> presentations, etc.). We would *really* appreciate feedback from
> everyone.

Where would I go to find someone's handicapped list of likely changes to
the language?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Howard Gardner wrote:
> > Howard Gardner wrote:
> >> I get the analogy: where is to template as where is to select.
> >>
> >> It will lead a lot of people to: template is to where as select is to
> >> where. If you work real hard, you can probably make that analogy fit in
> >> some fuzzy way, and end up with false notions as a result.

> The analogy to sql is weak. If you don't carefully qualify it, then it
> runs a large risk of conveying false things. If you do carefully qualify
> it, then it is verbose. In either event, it's just as easy to explain
> the behavior of where without the analogy at all.

Please excuse my ignorance here, but I have never used C#, while I am
familiar with SQL.  However, I don't understand what the problem is.
Maybe I've fallen victim to this exact pitfall and am just too stubborn
to even see it, but it seems to me that the insight I gain from SQL is
plenty.  Notwithstanding the fact that SQL is about selecting from
*existing* records, while C++ is about limiting which of the multitude
of possible templates are allowed to be instantiated, it seems to hold
up pretty well.

> Members of group B want to understand "where" in c++ and reflexively
> conjures sql or other weak analogies. They want to do GP in c++, have
> not learned to do it in c# or any other tool that uses the keyword
> "where" in the same way, but have used some tool that uses the keyword
> "where" in a different way. Choosing "where" hurts them.

I just don't get what you're saying here.  I'm not sure we can assume
that most SQL folks will take this analogy "too far" (which I'm not
sure I understand even), rather than just far enough to get helpful
insight from it.

> I think that group B is much larger than group A, and that group C is
> much larger than both of them together. I can't prove it.

> I'm in group B. When I read "where"
>
> http://www.artima.com/cppsource/cpp0x.html
>
> I conjured bad analogies which created confusion, and ended up thinking
> that "where" invokes "requires". This confusion persisted until I saw
> your objection to "requires", which prompted me to find
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1886.pdf
>
> from which I gleaned that "where" actually invokes "enable_if", and it's
> "assert" that invokes "requires".

And this is where my own understanding comes to the test -- First, I
didn't think "requires" was even a keyword anyone was considering.
This is my understanding of "where".  Please correct me if I'm wrong.
Adding a "where" clause to a template prevents it from being
instantiated in the first place.  So if I define

template <typename T> where Is_Numeric<T>
T sum_of_squares(T a, T b);

and then try to call sum_of_squares() on a pair of strings, I will get
an error that there is no function found with the correct signature.
This seems to be about the same as if I do a SELECT * FROM mytable
WHERE (index>10) but there are no records which match, despite the fact
that there *are* records in mytable.  In this case, the "FROM" or maybe
even the "SELECT *" is (weakly) analgous to the function signature,
which *does* match, and the WHERE is then rejecting whatever matches
where found.

Here is where I get even more confused by other people's confusion.  If
I were to write my above example as

template <typename T> T sum_of_squares(T a,T b) {
  static_assert<Is_Numeric<T> >;  // not sure about syntax, but you get
the idea
  return a*a+b*b;
}

then I would get possibly a more descriptive error message (string is
not numeric) than if I just defined it without the assert (string can't
be multiplied), but it seems that this solution is inherently flawed,
because it is already *instantiating* the template which we didn't want
to even instantiate in the first place.  This doesn't seem at all
analagous to WHERE from SQL.

> I think that this example illustrates the relationship between "where"
> and "assert".
>
> template< typename T >
>    where Assignable< T > // because of this
> void example()
> {
>    assert Assignable< T >; // this will never cause an error
> }

I agree -- but as explained above, I don't see the sense in this
statement.  "Where" and "assert" do very different things.  "Assert"
seems to me to be a safeguard applied after we already screwed up and
instantiated the wrong template, while "where" is a preventative
measure which makes sure we only instantiate the templates we really
mean to.

> This is the same example, except that both "where" and "assert" are
> replaced by "models".
>
> template< typename T >
>    models Assignable< T > // because of this
> void example()
> {
>    models Assignable< T >; // this will never cause an error
> }
>
> I think that this is clearer because the two uses of "models" are the
> same idea--that T models Assignable--occurring in two slightly different
> contexts, and it's the difference between the contexts that is important.

Here, I vehemently disagree, for reasons noted above.  It seems to me
that these two "model"s do very different things, since "where" and
"assert" really are different beasts.

Overall, I don't see a problem with "where" coming from a SQL point of
view.  Nor do I get the difference between "where" and "requires".  But
I hardly reckon my own experience much compared to the rest of the
folks posting here (and I certainly couldn't make it through either of
those technical articles), so if someone could enlighten me as to where
my misunderstanding is, or as to the specific problem they foresee, I
would really appreciate the insight.

Steve Hicks

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Steve Hicks wrote:
 > Howard Gardner wrote:
 >>> Howard Gardner wrote:
 >>>> I get the analogy: where is to template as where is to select.
 >>>>
 >>>> It will lead a lot of people to: template is to where as select is to
 >>>> where. If you work real hard, you can probably make that analogy
fit in
 >>>> some fuzzy way, and end up with false notions as a result.
 >
 >> The analogy to sql is weak. If you don't carefully qualify it, then it
 >> runs a large risk of conveying false things. If you do carefully qualify
 >> it, then it is verbose. In either event, it's just as easy to explain
 >> the behavior of where without the analogy at all.
 >
 > Please excuse my ignorance here, but I have never used C#, while I am
 > familiar with SQL.  However, I don't understand what the problem is.
 > Maybe I've fallen victim to this exact pitfall and am just too stubborn
 > to even see it, but it seems to me that the insight I gain from SQL is
 > plenty.  Notwithstanding the fact that SQL is about selecting from
 > *existing* records, while C++ is about limiting which of the multitude
 > of possible templates are allowed to be instantiated, it seems to hold
 > up pretty well.

You've conjured a better analogy than I did. Yours is better because it
didn't lead you to error. It's still not a good analogy, and you can tell.

Here's some code:

template<typename T>
   where LessThanComparable<T>
     const T & min(const T & l, const T & r);

Here's a straight explanation of it:

"The where clause indicates that the template will be considered during
overload resolution if and only if the type T models the concept
LessThanComparable."

The c# analogy is a good one, because apparently this is a good
alternative explanation:

"The where clause works like it does in c#."

The sql analogy is bad, because this alternative explanation is clearly
awful:

"The where clause works like it does in sql."

By the time you fix the explanation based on the sql analogy it s longer
than the straight explanation. That's the hallmark of a bad analogy: it
makes the explanation worse.

 >
 > And this is where my own understanding comes to the test -- First, I
 > didn't think "requires" was even a keyword anyone was considering.

Just me, and only while I was suffering from the confusion that my badly
conjured analogy caused me.

 > This is my understanding of "where".  Please correct me if I'm wrong.
 > Adding a "where" clause to a template prevents it from being
 > instantiated in the first place.  So if I define
 >
 > template <typename T> where Is_Numeric<T>
 > T sum_of_squares(T a, T b);
 >
 > and then try to call sum_of_squares() on a pair of strings, I will get
 > an error that there is no function found with the correct signature.

It does prevent it from being instantiated, but it specifically does
that by preventing it from even being considered for instantiation. The
compiler throws up an error referring to the call point in the user's
code, just as if the template wasn't there.

Contrast that with preventing it from being instantiated by discovering
an error during an attempt to instantiate it. That would cause the
compiler to throw up an error deep in the template.

The distinction is one of the feature's prime motivations.

 > This seems to be about the same as if I do a SELECT * FROM mytable
 > WHERE (index>10) but there are no records which match, despite the fact
 > that there *are* records in mytable.  In this case, the "FROM" or maybe
 > even the "SELECT *" is (weakly) analgous to the function signature,
 > which *does* match, and the WHERE is then rejecting whatever matches
 > where found.

Why on earth are we discussing SQL stuff in c.s.c++?

(Rhetorical. I'm making a point about another flaw with weak analogies:
they require a lot of discussion, which is only tangentially related to
the topic at hand. They are distracting.)

 >
 > Here is where I get even more confused by other people's confusion.  If
 > I were to write my above example as
 >
 > template <typename T> T sum_of_squares(T a,T b) {
 >   static_assert<Is_Numeric<T> >;  // not sure about syntax, but you get
 > the idea
 >   return a*a+b*b;
 > }
 >
 > then I would get possibly a more descriptive error message (string is
 > not numeric) than if I just defined it without the assert (string can't
 > be multiplied), but it seems that this solution is inherently flawed,
 > because it is already *instantiating* the template which we didn't want
 > to even instantiate in the first place.  This doesn't seem at all
 > analagous to WHERE from SQL.

The syntax from the paper is:

assert Is_Numeric<T>;

assert is another new keyword. If the assert fails, it causes an
immediate error. Hopefully, the diagnostic will indicate which part of
the concept T fails to model.

That will help people using templates. If the compiler tells you that
there is no match for T, then you can steal the where clause from the
template you think should match and turn it into an assert. The compiler
might then tell you what's wrong with T.

{
   string a, b;
   // sum_of_squares( a, b ); no match - why?!?!
   assert Is_Numeric< string >; // oh, I see
}

It will also help when writing templates, because it will help develop
with developing archetypes.

 >> I think that this example illustrates the relationship between "where"
 >> and "assert".
 >>
 >> template< typename T >
 >>    where Assignable< T > // because of this
 >> void example()
 >> {
 >>    assert Assignable< T >; // this will never cause an error
 >> }
 >
 > I agree -- but as explained above, I don't see the sense in this
 > statement.  "Where" and "assert" do very different things.  "Assert"
 > seems to me to be a safeguard applied after we already screwed up and
 > instantiated the wrong template, while "where" is a preventative
 > measure which makes sure we only instantiate the templates we really
 > mean to.

The only point in that code is to illustrate that Assignable is doing
the same thing in both places: checking T for syntax.

 >
 >> This is the same example, except that both "where" and "assert" are
 >> replaced by "models".
 >>
 >> template< typename T >
 >>    models Assignable< T > // because of this
 >> void example()
 >> {
 >>    models Assignable< T >; // this will never cause an error
 >> }
 >>
 >> I think that this is clearer because the two uses of "models" are the
 >> same idea--that T models Assignable--occurring in two slightly different
 >> contexts, and it's the difference between the contexts that is
important.
 >
 > Here, I vehemently disagree, for reasons noted above.  It seems to me
 > that these two "model"s do very different things, since "where" and
 > "assert" really are different beasts.

I counter-vehemently-disagree :)

Both uses of models are doing precisely the same thing. They are
checking type T for the syntax that it is required to have in order to
model the concept Assignable.

The difference lies entirely in the implication of failure. In the first
use, failure implies "ignore this template." In the second use, failure
implies "spew forth an diagnostic."

If this is the truth:

template< typename T >
   "consider instantiating this if T models Assignable"
void example()
{
   "spew a diagnostic if T does not model Assignable"
}

then transforming it to this:

template< typename T >
   where Assignable< T >
void example()
{
   assert Assignable< T >;
}

emphasizes the difference in the way that failure is treated.

Transforming it to this:

template< typename T >
   models Assignable< T >
void example()
{
   models Assignable< T >;
}

emphasizes the similarity in the test that is made.

I mildly prefer emphasizing the similar tests, strictly because doing so
would let us use one of GP's core vocabulary words (concept, model,
refinement, archetype) for the keyword. I think its a probably a little
easier to explain (and therefore to understand) everything that way. I'm
not sure though, and I wouldn't have bothered with arguing over that.

If it's better for some reason to emphasize the difference, though, then
this transform is easier to explain (and therefore to understand) than
the one using "where":

template< typename T >
   mcfrontalot Assignable< T >
void example()
{
   assert Assignable< T >;
}

It is easier to explain because the keyword "mcfrontalot" will not
conjure weak analogies that must be addressed.

It's like building a house, which is much easier to do on a vacant lot
than it is on the spot where another house stands.

 > Overall, I don't see a problem with "where" coming from a SQL point of
 > view.

It led me to an actively harmful analogy. You did better work, and so
arrived at an analogy that is merely useless.

 > Nor do I get the difference between "where" and "requires".

requires is a core vocabulary word from design by contract. I think that
Doug is right about using it for a keyword: it would probably conjure
bad analogies for people who do design by contract.

http://www.ddj.com/184405997
http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm

 > But I hardly reckon my own experience much compared to the rest of the
 > folks posting here (and I certainly couldn't make it through either of
 > those technical articles),

Meh, we're just programmers. Well, I am anyway.

 > so if someone could enlighten me as to where
 > my misunderstanding is, or as to the specific problem they foresee, I
 > would really appreciate the insight.
 >

I don't think you have a misunderstanding. Of course that might just
mean we both have the same misunderstanding. That's a real danger,
because we both founded our understanding on weak analogies. (Rhetorical
again. I'm pretty sure we've got it right now.)

I think that the best argument in favor of using "where" is that it
conjures strong analogies from some other languages. I think that the
best argument against using it is that it will conjure weak sql
analogies far more often.

I get the sense that this isn't really open to discussion, so I'll stop.
I've got some code to write anyway.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kanze wrote:
> ThosRTanner wrote:
>> Douglas Gregor wrote:
>
>>> This could be an issue. Every new keyword in C++0x is going
>>> to break existing code. We have to weigh the cost of
>>> breaking code against the cost of having keywords that are
>>> ugly or don't say what we want them to.
>
>> Isn't it possible to (re)design the compilers so that certain
>> keywords are only recognised as a keyword when it in the
>> context a keyword is appropriate, and other uses of it are
>> presumably expected to mean something else.
>
> It's certainly possible.  I once published a paper on how to
> modify yacc to support this.  I had to compile a language where
> something like "if if = then then then = else else else = if"
> was a perfectly legal statement.
>
> Whether it is a good idea or not is another question.  Examples
> like the above certainly don't argue in its favor.

I find the above example, of the use of 'where' in a particular context,
as precisely arguing in the suggestion's favor, which is an argument I
also made in this thread in answer to Doug Gregor's message at almost
exactly the same time.

Why do you then aver that this example does not argue in favor of
context sensitive keywords ?

>  And it
> doesn't really solve the problem of use in existing code---only
> banning the preprocessor would do that.

Context sensitive keywords perecisely solve the problem of use in
existing code for the vast majority of conflicts which could occur. Just
because someone could define a macro named 'where' is no reason to throw
out the whole concept of context sensitive keywords. Furthermore it is
common practice to use all uppercase alphabetics for macro names, which
would make a clash between a context sensitive keyword and a macro name
even rarer.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Edward Diener No Spam" <eldiener_no_spam_here@earthlink.net> wrote in
message news:JXWug.9574$PE1.7305@newsread2.news.pas.earthlink.net...

> In C++/CLI almost all of the new keywords are context sensitive and have
> little chance of impacting the use of those words by C++ programmers in
> their code. I do not see why C++ can not consider going in that direction
> also.

   Aren't some keywords already somewhat context sensitive?  I know that the
meaning of const and static varies depending on where in the program they
are used.  If the new semantics of "auto" are approved then it will also be
context sensitive.

Joe Gottman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Edward Diener No Spam posted:

> Furthermore it is common practice to use all uppercase alphabetics for
> macro names, which would make a clash between a context sensitive
> keyword and a macro name even rarer.


I would go further to condemn the use of lowercase letters for macro names
altogether, and not give them any consideration with regard to introducing
keywords.

Programmers certainly do have different styles; for example, some start the
name of a class or function with a capital letter, e.g.:

    class Catalogue {

    void Func()

while others don't.

However, has there ever been a substantial number of people who have used
lowercase names for macros?


--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Joe Gottman wrote:
> "Edward Diener No Spam" <eldiener_no_spam_here@earthlink.net> wrote in
> message news:JXWug.9574$PE1.7305@newsread2.news.pas.earthlink.net...
>
>> In C++/CLI almost all of the new keywords are context sensitive and have
>> little chance of impacting the use of those words by C++ programmers in
>> their code. I do not see why C++ can not consider going in that direction
>> also.
>
>    Aren't some keywords already somewhat context sensitive?

Not in this sense.

> I know that the
> meaning of const and static varies depending on where in the program they
> are used.  If the new semantics of "auto" are approved then it will also be
> context sensitive.

But it is always a keyword, as are const and static.  By
"context-sensitive keywords" we generally mean identifiers
which are keywords only in certain contexts.

My personal feeling is that clarity is impaired by such
identifiers.  C++ has few enough keywords that it is
reasonable to expect competent programmers to be familiar
with them all (which contrasts with the fact that it is
not reasonable to expect all competent C++ developers to
be familiar with every name in the standard library).

The only arguments for context-sensitive keywords appear
to be avoiding breakage of existing code, but I hold that
the cost in terms of lost clarity is not a good trade-off.

Using _Keywords with macros for more readable names is
also a losing proposition, as header files would have
to use the _Uglified versions in many cases, so readers
would need to be familiar with both forms.

I lean towards allowing economical use of new keywords
in C++0x, even at the cost of breaking some existing
code.  I'm not sure how much support that has within
the Committee; certainly many members are strongly
committed to minimizing such breakage, while others
(such as myself) feel that the cost of avoiding all
new keywords is too high.

static_assert appears to have already made it into the
working paper as a new keyword, so there's cause for
hope.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Joe Gottman wrote:
> "Edward Diener No Spam" <eldiener_no_spam_here@earthlink.net> wrote in
> message news:JXWug.9574$PE1.7305@newsread2.news.pas.earthlink.net...
>
>> In C++/CLI almost all of the new keywords are context sensitive and have
>> little chance of impacting the use of those words by C++ programmers in
>> their code. I do not see why C++ can not consider going in that direction
>> also.
>
>    Aren't some keywords already somewhat context sensitive?  I know that the
> meaning of const and static varies depending on where in the program they
> are used.  If the new semantics of "auto" are approved then it will also be
> context sensitive.

I agree that some keywords are context sensitive already, but what I am
arguing is that context sensitive keywords which could be added to the
language be also allowable as normal C++ names in all situations in
which they are not used in their context sensitive case(s). This would
mean that additions of certain context sensitive keywords to C++ would
not break user's code which now uses the keyword as a name, as long as
it can be guaranteed that the C++ name could not occur in exactly the
same position where the equivalent new context sensitive name would occur.

My suggestion is based on the fact that the standard C++ committee
appears to be highly concerned that any new additions to the C++
language not break any code which already exists. If the tack is always
taken is that new language additions, in the form of new keywords, could
always break current code based on the fact that a programmer could be
currently using the new keyword as a C++ name, my suggestion of new
keywords being possibly context sensitive could solve that problem
depending on the nature of the addition.

The proposed use of 'where' to restrict the types used as template
parameters is an excellent example of such a case. Another good current
example of this is the 'for' keyword, since 'for (..;..;..)' can never
mean anything else in C++, wvwn if 'for' were allowable as a C++ name. A
bad current example is the 'while' keyword, since 'while (..an
expression convertible to a boolean expression)' can mnemonically be
confused with the ever popular 'somename (..an expression convertible to
a boolean expression)' which could easily be a function call among many
other usages.

I just hate to think that the C++ language must forever be in stasis
because of the fear of breaking existing code in some way. Context
sensitive keywords offer a possible way out of that impasse.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:

    [...]
> However, has there ever been a substantial number of people
> who have used lowercase names for macros?

The authors of the Posix standard (and the authors of C).

Historically, in C, there have been two conventions.  And one
held that macros which could be used in place of a function
(function-like, didn't evaluate their arguments more than once,
etc.) should have names which looked like those of a function.
In C++, of course, I'd say use an inline function, but most of
us occasionally have to include a C header.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Edward Diener No Spam wrote:
> kanze wrote:
> > ThosRTanner wrote:
> >> Douglas Gregor wrote:

> >>> This could be an issue. Every new keyword in C++0x is
> >>> going to break existing code. We have to weigh the cost of
> >>> breaking code against the cost of having keywords that are
> >>> ugly or don't say what we want them to.

> >> Isn't it possible to (re)design the compilers so that
> >> certain keywords are only recognised as a keyword when it
> >> in the context a keyword is appropriate, and other uses of
> >> it are presumably expected to mean something else.

> > It's certainly possible.  I once published a paper on how to
> > modify yacc to support this.  I had to compile a language
> > where something like "if if = then then then = else else
> > else = if" was a perfectly legal statement.

> > Whether it is a good idea or not is another question.
> > Examples like the above certainly don't argue in its favor.

> I find the above example, of the use of 'where' in a
> particular context, as precisely arguing in the suggestion's
> favor, which is an argument I also made in this thread in
> answer to Doug Gregor's message at almost exactly the same
> time.

> Why do you then aver that this example does not argue in favor
> of context sensitive keywords ?

The "above example" I was referring to was the one I mentionned,
where if, then and else were both keywords and names of
variables.  It's a very extreme example, but it does show some
of the risks to be considered.  As a general rule, I would
oppose allowing keywords to be anything else.

Like all general rules, it probably allows exceptions.  If the
keyword is only legal in a very few, very special contexts, for
example, it is certainly less of a problem.  But I'm still
sceptical.

> >  And it doesn't really solve the problem of use in existing
> >  code---only banning the preprocessor would do that.

> Context sensitive keywords perecisely solve the problem of use
> in existing code for the vast majority of conflicts which
> could occur.

I'm afraid I just don't know what the vast majority of C++
programmers do, so I can't make such a statement.  I've never
defined a macro with the name where, but who knows.

But I wasn't trying to make an absolute point.  Simply to point
out that the solution isn't absolute with regards to breaking
user code.

> Just because someone could define a macro named 'where' is no
> reason to throw out the whole concept of context sensitive
> keywords.

No, but it does mean that the argument for doing so based on
avoiding breakage in existing code is less strong than it would
be otherwise.

> Furthermore it is common practice to use all uppercase
> alphabetics for macro names, which would make a clash between
> a context sensitive keyword and a macro name even rarer.

It may be common practice in your code, but it isn't everywhere.
Take a look at the headers for any Posix compliant system, for
example.  Or your C compiler.  Or some widely used third party
libraries, like [n]curses.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

David Abrahams wrote:
> hgardner@rawbw.com (Howard Gardner) writes:
>
>> If this is the code:
>>
>> template<typename T>
>>   requires LessThanComparable<T>
>>     const T &
>>       min(const T & l, const T & r);
>>
>> Then this explains it:
>>
>> "The requires clause indicates that the template can only be
>> instantiated for a type T if the type T models the concept
>> LessThanComparable".
>>
>> That explanation is shorter. Assuming that the reader understands
>> concept/models, it is clearer. It doesn't mention irrelevant things
>> like sql select. It doesn't rely on a weak analogy. It doesn't invite
>> false analogies.
>
> It also fails to capture the fact that the function isn't even
> considered for overload resolution if T isn't LessThanComparable, and

"The requires clause indicates that the template will be considered
during overload resolution if and only if the type T models the concept
LessThanComparable."

> doesn't leave much room in the imagination for refinement-based
> overload resolution.

The code does not illustrate this, so the explanation does not address it.

>
>> If you write the same explanation using the keyword "where", you
>> invite the reader to manufacture his own analogy. Using "where" brings
>> the analogy into play because "where" already has a deeply ingrained
>> meaning. You can either address it directly or not, but either way
>> you'll make things worse.
>
> I disagree.  Where is very good in this context, and it's made better
> by precedent in other languages.
>

"where" conjures a c# analogy for you rather than a sql analogy, right?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Douglas Gregor wrote:
> Howard Gardner wrote:
>> I get the analogy: where is to template as where is to select.
>>
>> It will lead a lot of people to: template is to where as select is to
>> where. If you work real hard, you can probably make that analogy fit in
>> some fuzzy way, and end up with false notions as a result.
>>
>> It's not fair that people perform illegitimate operations on analogies,
>> but they do.
>
> Push any analogy too far and it breaks down.
>
> I don't mean to imply that we should use the SQL analogy when teaching
> concepts/models, because I wouldn't do so. The analogy was meant only
> to illustrate that SQL "where" and concepts "where" serve essentially
> the same purpose: restricting the applicability of a select (SQL) or
> template (C++).
>

Explaining things by analogy can be good, or it can be bad.

If the analogy is strong then it conveys a lot of true things, there is
little risk of conveying false things, and it is succinct. It's good to
use strong analogies.

If the analogy is weak then it doesn't convey many true things, there is
great risk of conveying false things, or it is verbose. It's bad to use
weak analogies.

The analogy to sql is weak. If you don't carefully qualify it, then it
runs a large risk of conveying false things. If you do carefully qualify
it, then it is verbose. In either event, it's just as easy to explain
the behavior of where without the analogy at all.

>> If you write the same explanation using the keyword "where", you invite
>> the reader to manufacture his own analogy. Using "where" brings the
>> analogy into play because "where" already has a deeply ingrained
>> meaning. You can either address it directly or not, but either way
>> you'll make things worse.
>
> Everyone associates certain meanings with certain keywords... I see
> "requires" and I immediately think of preconditions, which document
> requirements that are checked at run-time or used for optimization, but
> are otherwise irrelevant to the declaration. That's certainly not the
> meaning we want for this clause, because (as Dave Abrahams points out)
> it doesn't capture how where-clauses interact with overloading and the
> type system.

I don't think that "requires" is ingrained in people's heads the way
that "where" is. It might, however, be pretty deeply ingrained in the
heads of people who are likely to be interested in the where clause.

> For some part of the C++ community, "where" has deeply-ingrained
> meanings from SQL. For others, it has deeply-ingrained meanings from
> C#. The C# analogy is strong ("where" means the same thing), whereas
> the SQL analogy is weak (even misleading, if pushed too far). By
> changing "where" to something else, we help the SQL group while hurting
> the C# group. Which group do we favor?

Members of group A want to understand "where" in c++ and reflexively
conjures c# or other strong analogies. They want to do GP in c++ and
have already learned to do it using c# or some other tool that uses
"where" in the same way. Choosing "where" helps them.

Members of group B want to understand "where" in c++ and reflexively
conjures sql or other weak analogies. They want to do GP in c++, have
not learned to do it in c# or any other tool that uses the keyword
"where" in the same way, but have used some tool that uses the keyword
"where" in a different way. Choosing "where" hurts them.

Members of group C want to understand "where" in c++ but don't
reflexively conjure any analogies at all. They want to do GP in c++ but
don't have any ingrained associations with the keyword "where". Choosing
"where" is neutral for them.

I think that group B is much larger than group A, and that group C is
much larger than both of them together. I can't prove it.

> I think that the damage caused
>> to the SQL group caused by the weak "where" analogy is far less than
>> the damage caused to the C# group by using a completely different
>> keyword for precisely the same facility in C#.

I'm in group B. When I read "where"

http://www.artima.com/cppsource/cpp0x.html

I conjured bad analogies which created confusion, and ended up thinking
that "where" invokes "requires". This confusion persisted until I saw
your objection to "requires", which prompted me to find

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1886.pdf

from which I gleaned that "where" actually invokes "enable_if", and it's
"assert" that invokes "requires".

That paper is pretty heavy going for me--because it relies on the
formalism in

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1885.pdf

so I *still* may have it wrong.

I think that this example illustrates the relationship between "where"
and "assert".

template< typename T >
   where Assignable< T > // because of this
void example()
{
   assert Assignable< T >; // this will never cause an error
}

This is the same example, except that both "where" and "assert" are
replaced by "models".

template< typename T >
   models Assignable< T > // because of this
void example()
{
   models Assignable< T >; // this will never cause an error
}

I think that this is clearer because the two uses of "models" are the
same idea--that T models Assignable--occurring in two slightly different
contexts, and it's the difference between the contexts that is important.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

ThosRTanner wrote:
> Douglas Gregor wrote:

> > This could be an issue. Every new keyword in C++0x is going
> > to break existing code. We have to weigh the cost of
> > breaking code against the cost of having keywords that are
> > ugly or don't say what we want them to.

> Isn't it possible to (re)design the compilers so that certain
> keywords are only recognised as a keyword when it in the
> context a keyword is appropriate, and other uses of it are
> presumably expected to mean something else.

It's certainly possible.  I once published a paper on how to
modify yacc to support this.  I had to compile a language where
something like "if if = then then then = else else else = if"
was a perfectly legal statement.

Whether it is a good idea or not is another question.  Examples
like the above certainly don't argue in its favor.  And it
doesn't really solve the problem of use in existing code---only
banning the preprocessor would do that.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Douglas Gregor wrote:
> derek@antiquark.com wrote:
> The "where" in SQL is used to limit the applicability of a query to
> results that meet the requirements stated in the where clause, e.g.,
>
>   SELECT * FROM Persons
>     WHERE City='Sandnes'
>
> This only accepts records that meet the requirement City='Sandnes'.
>
> The "where" in Concepts is used to limit the applicability of a
> template to parameters that meet the requirements stated in the where
> clause, e.g.,
>
>   template<typename T>
>     where LessThanComparable<T>
>     const T& min(const T& x, const T& y);
>
> This only accepts types T that meet the requirement
> 'LessThanComparable<T>' (or, "T is LessThanComparable").

I get the analogy: where is to template as where is to select.

It will lead a lot of people to: template is to where as select is to
where. If you work real hard, you can probably make that analogy fit in
some fuzzy way, and end up with false notions as a result.

It's not fair that people perform illegitimate operations on analogies,
but they do.

If this is the code:

template<typename T>
   requires LessThanComparable<T>
     const T &
       min(const T & l, const T & r);

Then this explains it:

"The requires clause indicates that the template can only be
instantiated for a type T if the type T models the concept
LessThanComparable".

That explanation is shorter. Assuming that the reader understands
concept/models, it is clearer. It doesn't mention irrelevant things like
sql select. It doesn't rely on a weak analogy. It doesn't invite false
analogies.

If you write the same explanation using the keyword "where", you invite
the reader to manufacture his own analogy. Using "where" brings the
analogy into play because "where" already has a deeply ingrained
meaning. You can either address it directly or not, but either way
you'll make things worse.

> [*] Pun intended.

!

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

hgardner@rawbw.com (Howard Gardner) writes:

> If this is the code:
>
> template<typename T>
>   requires LessThanComparable<T>
>     const T &
>       min(const T & l, const T & r);
>
> Then this explains it:
>
> "The requires clause indicates that the template can only be
> instantiated for a type T if the type T models the concept
> LessThanComparable".
>
> That explanation is shorter. Assuming that the reader understands
> concept/models, it is clearer. It doesn't mention irrelevant things
> like sql select. It doesn't rely on a weak analogy. It doesn't invite
> false analogies.

It also fails to capture the fact that the function isn't even
considered for overload resolution if T isn't LessThanComparable, and
doesn't leave much room in the imagination for refinement-based
overload resolution.

> If you write the same explanation using the keyword "where", you
> invite the reader to manufacture his own analogy. Using "where" brings
> the analogy into play because "where" already has a deeply ingrained
> meaning. You can either address it directly or not, but either way
> you'll make things worse.

I disagree.  Where is very good in this context, and it's made better
by precedent in other languages.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Howard Gardner wrote:
> I get the analogy: where is to template as where is to select.
>
> It will lead a lot of people to: template is to where as select is to
> where. If you work real hard, you can probably make that analogy fit in
> some fuzzy way, and end up with false notions as a result.
>
> It's not fair that people perform illegitimate operations on analogies,
> but they do.

Push any analogy too far and it breaks down.

I don't mean to imply that we should use the SQL analogy when teaching
concepts/models, because I wouldn't do so. The analogy was meant only
to illustrate that SQL "where" and concepts "where" serve essentially
the same purpose: restricting the applicability of a select (SQL) or
template (C++).

> If you write the same explanation using the keyword "where", you invite
> the reader to manufacture his own analogy. Using "where" brings the
> analogy into play because "where" already has a deeply ingrained
> meaning. You can either address it directly or not, but either way
> you'll make things worse.

Everyone associates certain meanings with certain keywords... I see
"requires" and I immediately think of preconditions, which document
requirements that are checked at run-time or used for optimization, but
are otherwise irrelevant to the declaration. That's certainly not the
meaning we want for this clause, because (as Dave Abrahams points out)
it doesn't capture how where-clauses interact with overloading and the
type system.

For some part of the C++ community, "where" has deeply-ingrained
meanings from SQL. For others, it has deeply-ingrained meanings from
C#. The C# analogy is strong ("where" means the same thing), whereas
the SQL analogy is weak (even misleading, if pushed too far). By
changing "where" to something else, we help the SQL group while hurting
the C# group. Which group do we favor? I think that the damage caused
to the SQL group caused by the weak "where" analogy is far less than
the damage caused to the C# group by using a completely different
keyword for precisely the same facility in C#.

  Doug

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"where" already has a deeply ingrained meaning (from SQL). I think that
you will generate a lot of confusion if you use it.

"requires" seems to express the relationship more clearly anyway.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Howard Gardner wrote:
> "where" already has a deeply ingrained meaning (from SQL). I think that
> you will generate a lot of confusion if you use it.

Also, it seems that "where" is already a popular variable name in C++:

<http://koders.com/?s=where&_%3Abtn=Search&_%3Ala=Cpp&_%3Ali=*>

<http://www.codase.com/search/text?join=where+&scope=variable%2Fname&lang=c%2B%2B&project=&search=Search>

And is used at least once in the linux kernel (C code):

<http://lxr.linux.no/ident?i=where>

Derek.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

derek@antiquark.com wrote:
> Howard Gardner wrote:
> > "where" already has a deeply ingrained meaning (from SQL). I think that
> > you will generate a lot of confusion if you use it.

Perhaps. It depends on whether the two "where"s could ever be used in
the same context (causing an ambiguity) and how divergent the meanings
actually are. In some cases, reuse of a name can help make new concept
[*] more accessible, by relating it to what the reader already
understands. Is this such a case? Perhaps it is:

The "where" in SQL is used to limit the applicability of a query to
results that meet the requirements stated in the where clause, e.g.,

  SELECT * FROM Persons
    WHERE City='Sandnes'

This only accepts records that meet the requirement City='Sandnes'.

The "where" in Concepts is used to limit the applicability of a
template to parameters that meet the requirements stated in the where
clause, e.g.,

  template<typename T>
    where LessThanComparable<T>
    const T& min(const T& x, const T& y);

This only accepts types T that meet the requirement
'LessThanComparable<T>' (or, "T is LessThanComparable").

Note that C# 2.0's generics use "where" for same same purpose (to
constrain a generic class/function). I wonder if they've run into
problems with SQL's "where"? I imagine it hasn't been a big problem,
since C# 3.0 looks like it will overload the "where" keyword
(introduced for generics) for its in-language SQL support. That would
surely complicate the problem.

> Also, it seems that "where" is already a popular variable name in C++:
>
> <http://koders.com/?s=where&_%3Abtn=Search&_%3Ala=Cpp&_%3Ali=*>
>
> <http://www.codase.com/search/text?join=where+&scope=variable%2Fname&lang=c%2B%2B&project=&search=Search>

This could be an issue. Every new keyword in C++0x is going to break
existing code. We have to weigh the cost of breaking code against the
cost of having keywords that are ugly or don't say what we want them
to.

> And is used at least once in the linux kernel (C code):
>
> <http://lxr.linux.no/ident?i=where>

Is the Linux kernel typically compiled with a C++ compiler? If not, we
don't need to worry about it.

  Cheers,
  Doug

[*] Pun intended.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Douglas Gregor wrote:
> derek@antiquark.com wrote:
>> Howard Gardner wrote:
>>> "where" already has a deeply ingrained meaning (from SQL). I think that
>>> you will generate a lot of confusion if you use it.
>
> Perhaps. It depends on whether the two "where"s could ever be used in
> the same context (causing an ambiguity) and how divergent the meanings
> actually are. In some cases, reuse of a name can help make new concept
> [*] more accessible, by relating it to what the reader already
> understands. Is this such a case? Perhaps it is:
>
> The "where" in SQL is used to limit the applicability of a query to
> results that meet the requirements stated in the where clause, e.g.,
>
>   SELECT * FROM Persons
>     WHERE City='Sandnes'
>
> This only accepts records that meet the requirement City='Sandnes'.
>
> The "where" in Concepts is used to limit the applicability of a
> template to parameters that meet the requirements stated in the where
> clause, e.g.,
>
>   template<typename T>
>     where LessThanComparable<T>
>     const T& min(const T& x, const T& y);
>
> This only accepts types T that meet the requirement
> 'LessThanComparable<T>' (or, "T is LessThanComparable").
>
> Note that C# 2.0's generics use "where" for same same purpose (to
> constrain a generic class/function). I wonder if they've run into
> problems with SQL's "where"? I imagine it hasn't been a big problem,
> since C# 3.0 looks like it will overload the "where" keyword
> (introduced for generics) for its in-language SQL support. That would
> surely complicate the problem.
>
>> Also, it seems that "where" is already a popular variable name in C++:
>>
>> <http://koders.com/?s=where&_%3Abtn=Search&_%3Ala=Cpp&_%3Ali=*>
>>
>> <http://www.codase.com/search/text?join=where+&scope=variable%2Fname&lang=c%2B%2B&project=&search=Search>
>
> This could be an issue. Every new keyword in C++0x is going to break
> existing code. We have to weigh the cost of breaking code against the
> cost of having keywords that are ugly or don't say what we want them
> to.
Perhaps C++ should begin to accept the idea, at least for any added
keywords at this juncture of the language, that the keyword when out of
context from its intended use can be a valid name. In the case of
'where', in which the proposal limits the type of a template in defined
ways, the use of 'where' in innumerable other contexts would suggest a
user-defined name and therefore not break other code.

In C++/CLI almost all of the new keywords are context sensitive and have
little chance of impacting the use of those words by C++ programmers in
their code. I do not see why C++ can not consider going in that
direction also.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Douglas Gregor wrote:
>
> This could be an issue. Every new keyword in C++0x is going to break
> existing code. We have to weigh the cost of breaking code against the
> cost of having keywords that are ugly or don't say what we want them
> to.
Isn't it possible to (re)design the compilers so that certain keywords
are only recognised as a keyword when it in the context a keyword is
appropriate, and other uses of it are presumably expected to mean
something else. The 'where' keyword for instance has a pretty
restricted context. Similarly for 'explicit' I think.

Or would that be considered as opening the doors to requests for all
keywords to be context sensitive?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Edward Diener No Spam wrote:
> Perhaps C++ should begin to accept the idea, at least for any added
> keywords at this juncture of the language, that the keyword when out of
> context from its intended use can be a valid name. In the case of
> 'where', in which the proposal limits the type of a template in defined
> ways, the use of 'where' in innumerable other contexts would suggest a
> user-defined name and therefore not break other code.
>
I agree.
There is at least one type of keyword for which it would be very easy
to implement : Types.
bool, wchar_t etc.
These types should be implemented "as if they were typedefs of
reserved, internal types".
It would solve a number of problems when linking C++ code to C
interfaces containing structure members with names such as bool.

I think that the rationale behind making builtin types as reserved
keywords, is that it would be a bad idea to use such names in newly
written code...
Who would suspect that a simple "bool" type could be a user-defined
typedef? Reading such code is not easy.

However, I don't think we must sacrifice backward compatibility and
compatibility with C code only for the sake of avoiding abuses.
Dumb programmers always find worst solutions, such as:

#define bool int

I've even seen once (on thedailywtf.com), not on my own:
#define true 0 /* yeah, zero, ZERO, it is not a typo */
#define false 1

If we add that dumb programmers prefer #define to typedef... We can see
that it would not change the world.

> In C++/CLI almost all of the new keywords are context sensitive and have
> little chance of impacting the use of those words by C++ programmers in
> their code. I do not see why C++ can not consider going in that
> direction also.
>
And in Scheme, *all* keywords can be hidden by local variables.
It obeys to the principles:
1) You don't pay for what you don't use.
2) You don't have to know the whole language (all keywords) before
using it.
Ok. You don't have to know the whole C++ language to use it... But
there is always a (small) risk of name collision with a keyword until
you know by heart the list of keywords.

It would also be possible to define all keywords in two different
flavours.
1) The weak keyword (e.g. bool)
2) A strong keyword that nobody could hide/redefine (e.g. _Bool)
Strong keywords would all be of the form
__keyword
Or
_Keyword

For consistency, the standard should choose one form between these two
forms, and keep it for all keywords.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]