Max T. Woodbury wrote:
> There are two ways around the sequencing problem.  The simplest would be to
> put the return type after the function name.  This would be a major
> change to
> declaration syntax and would break every "C" and "C++" program ever
> written.
> That makes this first possibly totally unacceptable.

It's not unacceptable if you make it an additional syntax that doesn't
replace the old one. In fact this syntax has already been proposed as a
part of the decltype/auto proposal
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1705.pdf). It
looks like this:

auto foo() -> int
{
  return 0;
}

which is meant to be perfectly equivalent to:

int foo()
{
  return 0;
}

with the only difference that the return type is parsed in the function
scope and not in the global scope, thus allowing:

Example::result_type operator ()(input_type in1, input_type in2)
{
    return in1 < in2;
}

to be written as:

auto operator ()(input_type in1, input_type in2) -> result_type
{
    return in1 < in2;
}

BTW, I find that using the keyword "return" instead of "->" would make
the syntax more readable, but it's a matter of taste.

Alberto

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

James Aguilar wrote:
> Max T. Woodbury wrote:
>
>>This causes technical parsing problems.  The return type of the function has
>>to be known to be a type to parse it properly.  In order to identify it as a
>>type in this context you need to know which class the member function belongs
>>to, but that information is not available until the 'Example::' is seen.  So
>>what you want to do is not possible given that parsing is a sequential
>>process.
>
> This is not the case.  Any LALR(1) parser should be able to put the return type
> lower on the Abstract Syntax Tree than the function node.  For instance, the
> syntax for the rule in CUP would be something like this:
>
> FunctionHeader ::= Typename:t Identifier:i OPAREN FParamList:fpl CPAREN
>     {:
>         RESULT = FunctionNode(i);
>         RESULT.addChild(t);
>         RESULT.addChild(fpl);
>     :}
>
> I do not know what it would look like in YACC or whatever the C++ compiler
> compiler is, but, to my knowledge, all of the set of compiler compilers use
> LALR(1) style parsers.
>
> And other such out of order syntax is easily permitted.  The return type could
> definitely be resolved to class scope without changing the accepted language
> very much, and certainly the current set of accepted programs could still be
> accepted with this modification.  Now, I can see another reason, and that's that
> the parameters -look- like they are scoped to the class, whereas the return type
> does not, but this argument is far from convincing for me.

Which CC is used depends on who's implementing the compiler of
course, but I think I saw a note that at least some of the better
compilers (that is the ones that programmers seem to like better)
do not use Compiler Compilers.  If I remember correctly, C++ is a
bit difficult to specify when you use the LALR approach.  You may
want to search the newsgroup archives for notes by Greg Comeau and
other implementors on what is involved.

You are correct that it is possible for a parser to deduce that the
first identifier is a type name and reparse the declaration, but that
requires a fair amount of backtracking, which can be troublesome.
(In other words I should have said 'not practical' rather than 'not
possible'.  I apologize for that.)  It also plays havoc with
overloading and templates from what little I have seen on these.
I suspect that there was a good reason for requiring a class tag on
the return type even if there was also one on the method identifier
as well.  I think you may be asking the compiler writers to go to a
lot of trouble for a very small gain to the programmers.  However
this is mostly speculation (but informed speculation) on my part and
I will gladly defer to someone with definitive knowledge.

>>There are two ways around the sequencing problem.  The simplest would be to
>>put the return type after the function name.  This would be a major change to
>>declaration syntax and would break every "C" and "C++" program ever written.
>>That makes this first possibly totally unacceptable.  The second would be
>>to make the context qualifier 'sticky'.  That is
>>
>>Example::result_type operator ()(input_type in1, input_type in2)
>>{
>>    return in1 < in2;
>>}
>
> This could possibly work but doesn't really make much sense in the overall
> context of "this method is part of a class.  Now everything else here is also
> part of that class."  "This return type is part of a class, now everything else
> is," is much less attractive.

That is putting it rather badly.  Think of it as "All of the following
relates to this class unless I tell you otherwise..."

max@mtew.isa-geek.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

James Aguilar wrote:
> Currently, when writing a member function in a class definition, typedefs that
> the programmer makes in the class allow member typedefs to be used as a return
> type, thus:
>
> class Example
> {
> public:
>   typedef bool result_type;
>   typedef int input_type;
>
>   result_type operator ()(input_type in1, input_type in2)
>   {
>     return in1 < in2;
>   }
> };
>
> However, when defining a member function outside of the class in which it is
> declared, it looks more like this:
>
> Example::result_type Example::operator ()(input_type in1, input_type in2)
> {
>   return in1 < in2;
> }
>
> and
>
> result_type Example::operator ()(input_type in1, input_type in2)
> {
>   return in1 < in2;
> }
>
> is illegal.  This should not be.  If the parameter types can be assumed to be
> members of the containing class, so should return types.  This has two benefits:
> first, it makes typedefs more useful -- when the typedefs must be qualified with
> their class's name, it makes them less of a time-saver because of the extra
> characters that must be typed, especially with the longer class names that
> descriptive naming sometimes requires.  Also, acceptance of this proposal would
> bring uniformity between return type usage of member typedefs and parameter
> usage of member typedefs.
>
> So: allow member typedefs to be used implicitly in both return types and
> parameter types.

This causes technical parsing problems.  The return type of the function has
to be known to be a type to parse it properly.  In order to identify it as a
type in this context you need to know which class the member function belongs
to, but that information is not available until the 'Example::' is seen.  So
what you want to do is not possible given that parsing is a sequential process.

There are two ways around the sequencing problem.  The simplest would be to
put the return type after the function name.  This would be a major change to
declaration syntax and would break every "C" and "C++" program ever written.
That makes this first possibly totally unacceptable.  The second would be
to make the context qualifier 'sticky'.  That is

Example::result_type operator ()(input_type in1, input_type in2)
{
     return in1 < in2;
}

would be an acceptable definition of 'Example::operator ()'.  How wise this
change to the language would be is another question of course and I have NO
opinion on that.

max@mtew.isa-geek.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]