Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: auto return type
113 views
Skip to first unread message
Sam
Jun 27, 2018, 5:15:13 PM6/27/18
to
Stefan Ram writes:
> But what about a function definition like:
>
> auto f(){ return 7; }
>
> ? A synopsis like
>
> Synopsis
> auto f();
>
> is hardly helpful. So should we avoid the auto return type
> for functions which are part of an API for this reason?
Avoiding a very useful, new language feature only because a documentation
tool can't deal with it doesn't seem like a good reason to me.
With the increased complexity of C++, only an actual C++ compiler can fully
understand C++ code. This is not the only part of modern C++ that doxygen
doesn't quite pick up.
I find doxygen very useful, and I use it a lot. I do not take into
consideration doxygen's limitations when writing code. I only review
doxygen's output after the fact; and make whatever manual fixes and tweaks
to doxygen's output that can be reasonably done.
> But what about a function definition like:
>
> auto f(){ return 7; }
>
> ? A synopsis like
>
> Synopsis
> auto f();
>
> is hardly helpful. So should we avoid the auto return type
> for functions which are part of an API for this reason?
Avoiding a very useful, new language feature only because a documentation
tool can't deal with it doesn't seem like a good reason to me.
With the increased complexity of C++, only an actual C++ compiler can fully
understand C++ code. This is not the only part of modern C++ that doxygen
doesn't quite pick up.
I find doxygen very useful, and I use it a lot. I do not take into
consideration doxygen's limitations when writing code. I only review
doxygen's output after the fact; and make whatever manual fixes and tweaks
to doxygen's output that can be reasonably done.
Paavo Helde
Jun 27, 2018, 5:34:45 PM6/27/18
to
On 27.06.2018 23:29, Stefan Ram wrote:
> Tools like Doxygen copy the head of a function definition
> to double as documentation:
>
> Synopsis
> int f();
>
> , and, of course, the "Synopsis" gives us the return type.
However, auto return type should be avoided in API-s because an API
ought to define an interface (that's the I) but auto depends on the
implementation details. With something having an official API it should
be vice versa, implementation should depend on the interface.
> Tools like Doxygen copy the head of a function definition
> to double as documentation:
>
> Synopsis
> int f();
>
> , and, of course, the "Synopsis" gives us the return type.
>
> But what about a function definition like:
>
> auto f(){ return 7; }
>
> ? A synopsis like
>
> Synopsis
> auto f();
>
> is hardly helpful. So should we avoid the auto return type
> for functions which are part of an API for this reason?
Nope, the tools should be updated to cope with the new language rules.
> But what about a function definition like:
>
> auto f(){ return 7; }
>
> ? A synopsis like
>
> Synopsis
> auto f();
>
> is hardly helpful. So should we avoid the auto return type
> for functions which are part of an API for this reason?
However, auto return type should be avoided in API-s because an API
ought to define an interface (that's the I) but auto depends on the
implementation details. With something having an official API it should
be vice versa, implementation should depend on the interface.
Chris M. Thomasson
Jun 27, 2018, 5:38:05 PM6/27/18
to
On 6/27/2018 2:34 PM, Paavo Helde wrote:
> On 27.06.2018 23:29, Stefan Ram wrote:
>> Tools like Doxygen copy the head of a function definition
>> to double as documentation:
>>
>> Synopsis
>> int f();
>>
>> , and, of course, the "Synopsis" gives us the return type.
>>
>> But what about a function definition like:
>>
>> auto f(){ return 7; }
>>
>> ? A synopsis like
>>
>> Synopsis
>> auto f();
>>
>> is hardly helpful. So should we avoid the auto return type
>> for functions which are part of an API for this reason?
>
> Nope, the tools should be updated to cope with the new language rules.
>
> However, auto return type should be avoided in API-s
Agreed.
> On 27.06.2018 23:29, Stefan Ram wrote:
>> Tools like Doxygen copy the head of a function definition
>> to double as documentation:
>>
>> Synopsis
>> int f();
>>
>> , and, of course, the "Synopsis" gives us the return type.
>>
>> But what about a function definition like:
>>
>> auto f(){ return 7; }
>>
>> ? A synopsis like
>>
>> Synopsis
>> auto f();
>>
>> is hardly helpful. So should we avoid the auto return type
>> for functions which are part of an API for this reason?
>
> Nope, the tools should be updated to cope with the new language rules.
>
> However, auto return type should be avoided in API-s
Alf P. Steinbach
Jun 27, 2018, 6:06:20 PM6/27/18
to
On 27.06.2018 23:34, Paavo Helde wrote:
> On 27.06.2018 23:29, Stefan Ram wrote:
>> Tools like Doxygen copy the head of a function definition
>> to double as documentation:
>>
>> Synopsis
>> int f();
>>
>> , and, of course, the "Synopsis" gives us the return type.
>>
>> But what about a function definition like:
>>
>> auto f(){ return 7; }
>>
>> ? A synopsis like
>>
>> Synopsis
>> auto f();
>>
>> is hardly helpful. So should we avoid the auto return type
>> for functions which are part of an API for this reason?
>
> Nope, the tools should be updated to cope with the new language rules.
>
> However, auto return type should be avoided in API-s
I think you mean deduced return type, because then this makes sense:
> On 27.06.2018 23:29, Stefan Ram wrote:
>> Tools like Doxygen copy the head of a function definition
>> to double as documentation:
>>
>> Synopsis
>> int f();
>>
>> , and, of course, the "Synopsis" gives us the return type.
>>
>> But what about a function definition like:
>>
>> auto f(){ return 7; }
>>
>> ? A synopsis like
>>
>> Synopsis
>> auto f();
>>
>> is hardly helpful. So should we avoid the auto return type
>> for functions which are part of an API for this reason?
>
> Nope, the tools should be updated to cope with the new language rules.
>
> However, auto return type should be avoided in API-s
> because an API
> ought to define an interface (that's the I) but auto depends on the
> implementation details. With something having an official API it should
> be vice versa, implementation should depend on the interface.
- Alf
Chris Vine
Jun 27, 2018, 7:56:19 PM6/27/18
to
On 27 Jun 2018 20:29:34 GMT
instead avoid C++14 deduced return types where you actually know what
the return type is, except in the case of short lambda expressions, as
a matter of good form and making your code intelligible. This is apart
from the documentation difficulties to which you refer.
Where you don't necessarily know what the return type is, this was
rather more self-documenting with C++11. With C++11 when deducing
return types you had to have a trailing return type specified using a
decltype expression (or std::result_of) except in the case of single
statement lambda expressions (I think, it's going back a bit now).
Doxygen does correctly document that form for you. There is nothing to
stop you doing that with C++14 also, but this sort-of offends the DRY
principle since it is duplicative.
I have only mainly used auto with C++14 deduced return types in cases,
say in template code, where you do not actually know what the return
type is in advance. This is often coupled with the use of decltype on
the function having that deduced return type[1], because the function
is used for compile time metaprogramming and is never actually executed
at all.
Usually such functions with deduced return types are not part of the
public API anyway. Where they are, I think the documentation should
explain the position.
Chris
[1] This is decltype applied to the function application itself, in
order to generate a type. It is not the same as using decltype in a
C++11 style auto return type function declaration.
r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Tools like Doxygen copy the head of a function definition
> to double as documentation:
>
> Synopsis
> int f();
>
> , and, of course, the "Synopsis" gives us the return type.
>
> But what about a function definition like:
>
> auto f(){ return 7; }
>
> ? A synopsis like
>
> Synopsis
> auto f();
>
> is hardly helpful. So should we avoid the auto return type
> for functions which are part of an API for this reason?
I think this is a bit of a side issue. My view is that you should
> Tools like Doxygen copy the head of a function definition
> to double as documentation:
>
> Synopsis
> int f();
>
> , and, of course, the "Synopsis" gives us the return type.
>
> But what about a function definition like:
>
> auto f(){ return 7; }
>
> ? A synopsis like
>
> Synopsis
> auto f();
>
> is hardly helpful. So should we avoid the auto return type
> for functions which are part of an API for this reason?
instead avoid C++14 deduced return types where you actually know what
the return type is, except in the case of short lambda expressions, as
a matter of good form and making your code intelligible. This is apart
from the documentation difficulties to which you refer.
Where you don't necessarily know what the return type is, this was
rather more self-documenting with C++11. With C++11 when deducing
return types you had to have a trailing return type specified using a
decltype expression (or std::result_of) except in the case of single
statement lambda expressions (I think, it's going back a bit now).
Doxygen does correctly document that form for you. There is nothing to
stop you doing that with C++14 also, but this sort-of offends the DRY
principle since it is duplicative.
I have only mainly used auto with C++14 deduced return types in cases,
say in template code, where you do not actually know what the return
type is in advance. This is often coupled with the use of decltype on
the function having that deduced return type[1], because the function
is used for compile time metaprogramming and is never actually executed
at all.
Usually such functions with deduced return types are not part of the
public API anyway. Where they are, I think the documentation should
explain the position.
Chris
[1] This is decltype applied to the function application itself, in
order to generate a type. It is not the same as using decltype in a
C++11 style auto return type function declaration.
Juha Nieminen
Jun 28, 2018, 1:20:22 AM6/28/18
to
Paavo Helde <myfir...@osa.pri.ee> wrote:
> However, auto return type should be avoided in API-s because an API
> ought to define an interface (that's the I) but auto depends on the
> implementation details. With something having an official API it should
> be vice versa, implementation should depend on the interface.
Note that using 'auto' in an API might sometimes be justified.
> However, auto return type should be avoided in API-s because an API
> ought to define an interface (that's the I) but auto depends on the
> implementation details. With something having an official API it should
> be vice versa, implementation should depend on the interface.
More particularly as a synonym for "none-of-your-business type".
I'm not joking. The most prominent example of this would be
the actual type of a lambda. It's quite literally "none of your
business". The programmer shouldn't concern himself about what
the actual type of a lambda is, hence it's always used as 'auto'.
The actual underlying type is unspecified, and up to the compiler,
and code using lambda should never try to use that type explicitly.
David Brown
Jun 28, 2018, 4:49:11 AM6/28/18
to
On 27/06/18 22:29, Stefan Ram wrote:
> Tools like Doxygen copy the head of a function definition
> to double as documentation:
>
> Synopsis
> int f();
>
> , and, of course, the "Synopsis" gives us the return type.
>
> But what about a function definition like:
>
> auto f(){ return 7; }
>
> ? A synopsis like
>
> Synopsis
> auto f();
>
> is hardly helpful. So should we avoid the auto return type
> for functions which are part of an API for this reason?
>
No, you should avoid having the auto return type in an API because it is
> Tools like Doxygen copy the head of a function definition
> to double as documentation:
>
> Synopsis
> int f();
>
> , and, of course, the "Synopsis" gives us the return type.
>
> But what about a function definition like:
>
> auto f(){ return 7; }
>
> ? A synopsis like
>
> Synopsis
> auto f();
>
> is hardly helpful. So should we avoid the auto return type
> for functions which are part of an API for this reason?
>
a daft thing to have in an API. An API should be specific, and say
/exactly/ what it returns. (In cases where that is impossible, such as
in some template functions, you need to question your coding structure
and API design before resorting to auto.)
"auto" is extremely convenient for local functions - static functions,
anonymous namespaces, private methods, etc. It is not something you
would want in an API. That applies to functions, variables, consts, etc.
bol...@cylonhq.com
Jun 28, 2018, 5:40:54 AM6/28/18
to
On Wed, 27 Jun 2018 17:14:59 -0400
Sam <s...@email-scan.com> wrote:
>With the increased complexity of C++, only an actual C++ compiler can fully
>understand C++ code. This is not the only part of modern C++ that doxygen
>doesn't quite pick up.
IMO the C++ syntax has now jumped the shark, its far to complex and rivals
Sam <s...@email-scan.com> wrote:
>With the increased complexity of C++, only an actual C++ compiler can fully
>understand C++ code. This is not the only part of modern C++ that doxygen
>doesn't quite pick up.
Perl in its hideousnous. Originally it was commented that uglies such as
"virtual func() = 0" instead of "pure virtual func()" were because extra
keywords may break older programs that use them as names elsewhere. Then
we had new keywords such as override, final, explicit etc added anyway making
that argument moot. Then things got work and IMO the syntax reached its
nadir with the "[=/&]() -> <return type> { }" horror of lambda functions.
We have std::function. Why the hell didn't they simply introduce std::lambda
with a similar syntax?
eg: std::lambda<int((<local scoped vars>,(parameters)> { }
Or just do what other languages do and use the same syntax as primary functions
eg:
func(int mylambda(a,b,c) { }) or similar?
Chris Vine
Jun 28, 2018, 10:20:40 AM6/28/18
to
On Thu, 28 Jun 2018 09:40:42 +0000 (UTC)
bol...@cylonHQ.com wrote:
> IMO the C++ syntax has now jumped the shark, its far to complex and rivals
> Perl in its hideousnous. Originally it was commented that uglies such as
> "virtual func() = 0" instead of "pure virtual func()" were because extra
> keywords may break older programs that use them as names elsewhere.
A pure function means something completely different. That would be a
bol...@cylonHQ.com wrote:
> IMO the C++ syntax has now jumped the shark, its far to complex and rivals
> Perl in its hideousnous. Originally it was commented that uglies such as
> "virtual func() = 0" instead of "pure virtual func()" were because extra
> keywords may break older programs that use them as names elsewhere.
very poor choice of words, quite apart from needing a new keyword.
> Then
> we had new keywords such as override, final, explicit etc added anyway making
> that argument moot.
of having override, final and explicit as keywords outweighed the
potential for breakage, which would have been very small.
> Then things got work and IMO the syntax reached its
> nadir with the "[=/&]() -> <return type> { }" horror of lambda functions.
>
> We have std::function. Why the hell didn't they simply introduce std::lambda
> with a similar syntax?
>
> eg: std::lambda<int((<local scoped vars>,(parameters)> { }
parameters are already separated by commas? Or are you inventing
a new meaning for parentheses (it is not clear because yours are
unbalanced). This syntax is hopeless. I prefer what we have.
> Or just do what other languages do and use the same syntax as primary functions
> eg:
>
> func(int mylambda(a,b,c) { }) or similar?
the captured variables and whether the capture is to be by reference or
by value. To try to introduce automatic lexical closures as in
some other languages would have been a significant alteration to C++ and
wouldn't have worked. Languages which do have that generally work on
the basis that numbers and characters (so called "immediate" values) are
copied by value and any other object is copied by reference.
I think you are too easily offended by language syntax. Try another
language - there are plenty to choose from.
bol...@cylonhq.com
Jun 28, 2018, 10:34:44 AM6/28/18
to
On Thu, 28 Jun 2018 15:20:20 +0100
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>On Thu, 28 Jun 2018 09:40:42 +0000 (UTC)
>bol...@cylonHQ.com wrote:
>> IMO the C++ syntax has now jumped the shark, its far to complex and rivals
>> Perl in its hideousnous. Originally it was commented that uglies such as
>> "virtual func() = 0" instead of "pure virtual func()" were because extra
>> keywords may break older programs that use them as names elsewhere.
>
>A pure function means something completely different. That would be a
It does? Please enlighten us because in C++ the "= 0" on the end definately
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>On Thu, 28 Jun 2018 09:40:42 +0000 (UTC)
>bol...@cylonHQ.com wrote:
>> IMO the C++ syntax has now jumped the shark, its far to complex and rivals
>> Perl in its hideousnous. Originally it was commented that uglies such as
>> "virtual func() = 0" instead of "pure virtual func()" were because extra
>> keywords may break older programs that use them as names elsewhere.
>
>A pure function means something completely different. That would be a
means pure virtual. Perhaps you're getting confused with another language.
>> we had new keywords such as override, final, explicit etc added anyway making
>
>> that argument moot.
>
>The argument is never moot. Presumably it was felt that the advantages
>of having override, final and explicit as keywords outweighed the
>potential for breakage, which would have been very small.
>> eg: std::lambda<int((<local scoped vars>,(parameters)> { }
>
>A comma separating the captured variables from parameters, when
>parameters are already separated by commas? Or are you inventing
>a new meaning for parentheses (it is not clear because yours are
>unbalanced). This syntax is hopeless. I prefer what we have.
>I think you are too easily offended by language syntax. Try another
>language - there are plenty to choose from.
long time to become proficient in anyway. I have better things to do with my
time than start from scratch.
Chris Vine
Jun 28, 2018, 10:59:03 AM6/28/18
to
On Thu, 28 Jun 2018 14:34:30 +0000 (UTC)
bol...@cylonHQ.com wrote:
> On Thu, 28 Jun 2018 15:20:20 +0100
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> >On Thu, 28 Jun 2018 09:40:42 +0000 (UTC)
> >bol...@cylonHQ.com wrote:
> >> IMO the C++ syntax has now jumped the shark, its far to complex and rivals
> >> Perl in its hideousnous. Originally it was commented that uglies such as
> >> "virtual func() = 0" instead of "pure virtual func()" were because extra
> >> keywords may break older programs that use them as names elsewhere.
> >
> >A pure function means something completely different. That would be a
>
> It does? Please enlighten us because in C++ the "= 0" on the end definately
> means pure virtual. Perhaps you're getting confused with another language.
Look it up, and give yourself a broader background. If 'pure' were to
bol...@cylonHQ.com wrote:
> On Thu, 28 Jun 2018 15:20:20 +0100
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> >On Thu, 28 Jun 2018 09:40:42 +0000 (UTC)
> >bol...@cylonHQ.com wrote:
> >> IMO the C++ syntax has now jumped the shark, its far to complex and rivals
> >> Perl in its hideousnous. Originally it was commented that uglies such as
> >> "virtual func() = 0" instead of "pure virtual func()" were because extra
> >> keywords may break older programs that use them as names elsewhere.
> >
> >A pure function means something completely different. That would be a
>
> It does? Please enlighten us because in C++ the "= 0" on the end definately
> means pure virtual. Perhaps you're getting confused with another language.
be used as a keyword, it would be to mark that a function is without
side effects, not to indicate that it is a virtual function without
implementation. Various languages have a 'pure' keyword, such as D; I
would not especially support its introduction in C++ but it should be
left alone for that use in case in the future others decide otherwise
as it may possibly have optimization benefits; it should not be expended
to give effect to your proposal.
> >> we had new keywords such as override, final, explicit etc added anyway making
> >
> >> that argument moot.
> >
> >The argument is never moot. Presumably it was felt that the advantages
> >of having override, final and explicit as keywords outweighed the
> >potential for breakage, which would have been very small.
>
> Ditto "pure".
explicit' as keywords means a free for all for any other half-baked
keyword anyone on a newsgroup thinks should be used, because it is now
"moot", is ridiculous. It is even more ridiculous when 'pure' already
has a well accepted and different meaning.
> >> eg: std::lambda<int((<local scoped vars>,(parameters)> { }
> >
> >A comma separating the captured variables from parameters, when
> >parameters are already separated by commas? Or are you inventing
>
> My mistake, I meant to write ";" as used in for().
>
> >a new meaning for parentheses (it is not clear because yours are
> >unbalanced). This syntax is hopeless. I prefer what we have.
>
> Presumably you think the std::function syntax is hopeless too then.
of std::function does not provide for it to do so. If you want to have
a closure with std::function you have to construct it specifically with
a lambda expression, std::bind or the like. In fact, you have
deliberately snipped the part of my post which previously explained this
to you.
> >I think you are too easily offended by language syntax. Try another
>
> I'm offended by hacks, which is what C++ seems to be descending into.
>
> >language - there are plenty to choose from.
>
> Most are flavour of the month with little real traction and any language take a
> long time to become proficient in anyway. I have better things to do with my
> time than start from scratch.
that you know it all when it is apparent that you do not.
bol...@cylonhq.com
Jun 28, 2018, 11:06:40 AM6/28/18
to
On Thu, 28 Jun 2018 15:58:45 +0100
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>On Thu, 28 Jun 2018 14:34:30 +0000 (UTC)
>bol...@cylonHQ.com wrote:
>> It does? Please enlighten us because in C++ the "= 0" on the end definately
>> means pure virtual. Perhaps you're getting confused with another language.
>
>Look it up, and give yourself a broader background. If 'pure' were to
>be used as a keyword, it would be to mark that a function is without
>side effects, not to indicate that it is a virtual function without
>implementation. Various languages have a 'pure' keyword, such as D; I
In C++ that is the definition of pure. This discussion is about C++ not
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>On Thu, 28 Jun 2018 14:34:30 +0000 (UTC)
>bol...@cylonHQ.com wrote:
>> It does? Please enlighten us because in C++ the "= 0" on the end definately
>> means pure virtual. Perhaps you're getting confused with another language.
>
>Look it up, and give yourself a broader background. If 'pure' were to
>be used as a keyword, it would be to mark that a function is without
>side effects, not to indicate that it is a virtual function without
>implementation. Various languages have a 'pure' keyword, such as D; I
the general definition of pure virtuals as you see it.
>> Ditto "pure".
>
>No - see above. Your proposition that having 'overide, final and
>"moot", is ridiculous. It is even more ridiculous when 'pure' already
>has a well accepted and different meaning.
>Broadening your knowledge would help you avoid the temptation to think
>that you know it all when it is apparent that you do not.
I suggest you get your own clue.
Chris Vine
Jun 28, 2018, 11:25:40 AM6/28/18
to
On Thu, 28 Jun 2018 15:06:27 +0000 (UTC)
bol...@cylonHQ.com wrote:
> On Thu, 28 Jun 2018 15:58:45 +0100
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> >On Thu, 28 Jun 2018 14:34:30 +0000 (UTC)
> >bol...@cylonHQ.com wrote:
> >> It does? Please enlighten us because in C++ the "= 0" on the end definately
> >> means pure virtual. Perhaps you're getting confused with another language.
> >
> >Look it up, and give yourself a broader background. If 'pure' were to
> >be used as a keyword, it would be to mark that a function is without
> >side effects, not to indicate that it is a virtual function without
> >implementation. Various languages have a 'pure' keyword, such as D; I
>
> In C++ that is the definition of pure. This discussion is about C++ not
> the general definition of pure virtuals as you see it.
Pure functions are rarely virtual. Anyone with minimal knowledge of
bol...@cylonHQ.com wrote:
> On Thu, 28 Jun 2018 15:58:45 +0100
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> >On Thu, 28 Jun 2018 14:34:30 +0000 (UTC)
> >bol...@cylonHQ.com wrote:
> >> It does? Please enlighten us because in C++ the "= 0" on the end definately
> >> means pure virtual. Perhaps you're getting confused with another language.
> >
> >Look it up, and give yourself a broader background. If 'pure' were to
> >be used as a keyword, it would be to mark that a function is without
> >side effects, not to indicate that it is a virtual function without
> >implementation. Various languages have a 'pure' keyword, such as D; I
>
> In C++ that is the definition of pure. This discussion is about C++ not
> the general definition of pure virtuals as you see it.
computer science knows what a pure function is.
> >> Ditto "pure".
> >
> >No - see above. Your proposition that having 'overide, final and
>
> Yes.
>
> >"moot", is ridiculous. It is even more ridiculous when 'pure' already
> >has a well accepted and different meaning.
>
> Not in C++.
>
> >Broadening your knowledge would help you avoid the temptation to think
> >that you know it all when it is apparent that you do not.
>
> Spare me your feeble attempts at being patronising, they're falling flat.
> I suggest you get your own clue.
for yourself. I genuinely was suggesting that you need to widen your
experience in order to help deal with that.
bol...@cylonhq.com
Jun 28, 2018, 11:34:29 AM6/28/18
to
On Thu, 28 Jun 2018 16:25:23 +0100
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>On Thu, 28 Jun 2018 15:06:27 +0000 (UTC)
>bol...@cylonHQ.com wrote:
>> In C++ that is the definition of pure. This discussion is about C++ not
>> the general definition of pure virtuals as you see it.
>
>Pure functions are rarely virtual. Anyone with minimal knowledge of
>computer science knows what a pure function is.
We're not talking about the mathematical definition of pure, we're talking
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>On Thu, 28 Jun 2018 15:06:27 +0000 (UTC)
>bol...@cylonHQ.com wrote:
>> In C++ that is the definition of pure. This discussion is about C++ not
>> the general definition of pure virtuals as you see it.
>
>Pure functions are rarely virtual. Anyone with minimal knowledge of
>computer science knows what a pure function is.
about the c++ definition of pure virtuals which mean something else entirely.
Either you're being pedantic for the sake of it or you're just another
aspie unable to follow normal discussion.
>> Spare me your feeble attempts at being patronising, they're falling flat.
>> I suggest you get your own clue.
>
>I don't need to be patronizing. You seem clueless, and you do it all
>for yourself. I genuinely was suggesting that you need to widen your
>experience in order to help deal with that.
Chris Vine
Jun 28, 2018, 11:59:03 AM6/28/18
to
On Thu, 28 Jun 2018 15:34:15 +0000 (UTC)
bol...@cylonHQ.com wrote:
> On Thu, 28 Jun 2018 16:25:23 +0100
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> >On Thu, 28 Jun 2018 15:06:27 +0000 (UTC)
> >bol...@cylonHQ.com wrote:
> >> In C++ that is the definition of pure. This discussion is about C++ not
> >> the general definition of pure virtuals as you see it.
> >
> >Pure functions are rarely virtual. Anyone with minimal knowledge of
> >computer science knows what a pure function is.
>
> We're not talking about the mathematical definition of pure, we're talking
> about the c++ definition of pure virtuals which mean something else entirely.
> Either you're being pedantic for the sake of it or you're just another
> aspie unable to follow normal discussion.
If I were, that would be a totally inappropriate remark to make. Ad
bol...@cylonHQ.com wrote:
> On Thu, 28 Jun 2018 16:25:23 +0100
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> >On Thu, 28 Jun 2018 15:06:27 +0000 (UTC)
> >bol...@cylonHQ.com wrote:
> >> In C++ that is the definition of pure. This discussion is about C++ not
> >> the general definition of pure virtuals as you see it.
> >
> >Pure functions are rarely virtual. Anyone with minimal knowledge of
> >computer science knows what a pure function is.
>
> We're not talking about the mathematical definition of pure, we're talking
> about the c++ definition of pure virtuals which mean something else entirely.
> Either you're being pedantic for the sake of it or you're just another
> aspie unable to follow normal discussion.
hominem remarks of that kind would just be an indication that you have
lost the argument. So you seem not only to be lacking understanding
about C++, but to be unpleasant and lacking understanding about C++.
Anyway, you carry on with your fixation with pure virtual functions.
Better informed people would want to reserve any 'pure' keyword to
denote pure functions.
Richard
Jun 28, 2018, 12:16:05 PM6/28/18
to
[Please do not mail me a copy of your followup]
Sam <s...@email-scan.com> spake the secret code
<cone.1530134100...@monster.email-scan.com> thusly:
>With the increased complexity of C++, only an actual C++ compiler can fully
>understand C++ code. This is not the only part of modern C++ that doxygen
>doesn't quite pick up.
Use DoxyPress instead; it uses clang to parse.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Sam <s...@email-scan.com> spake the secret code
<cone.1530134100...@monster.email-scan.com> thusly:
>With the increased complexity of C++, only an actual C++ compiler can fully
>understand C++ code. This is not the only part of modern C++ that doxygen
>doesn't quite pick up.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
james...@alumni.caltech.edu
Jun 28, 2018, 11:49:40 PM6/28/18
to
On Thursday, June 28, 2018 at 10:20:40 AM UTC-4, Chris Vine wrote:
> On Thu, 28 Jun 2018 09:40:42 +0000 (UTC)
> bol...@cylonHQ.com wrote:
> > IMO the C++ syntax has now jumped the shark, its far to complex and rivals
> > Perl in its hideousnous. Originally it was commented that uglies such as
> > "virtual func() = 0" instead of "pure virtual func()" were because extra
> > keywords may break older programs that use them as names elsewhere.
>
> A pure function means something completely different. That would be a
> very poor choice of words, quite apart from needing a new keyword.
We're talking about C++ here. The C++ standard defines what the term
> On Thu, 28 Jun 2018 09:40:42 +0000 (UTC)
> bol...@cylonHQ.com wrote:
> > IMO the C++ syntax has now jumped the shark, its far to complex and rivals
> > Perl in its hideousnous. Originally it was commented that uglies such as
> > "virtual func() = 0" instead of "pure virtual func()" were because extra
> > keywords may break older programs that use them as names elsewhere.
>
> A pure function means something completely different. That would be a
> very poor choice of words, quite apart from needing a new keyword.
"pure virtual function" means in the context of C++ (10.4p2). Like many
other pieces of C++ jargon, you can't interpret it correctly by
interpreting it word for word according to the generally accepted
meanings of those words - the only way to correctly understand what the
phrase means in a C++ context is to read what the C++ standard says
about such functions. That definition does not correspond to "a pure
function in the mathematical sense which is also virtual".
This is not a particularly odd occurrence in C++ - consider the term
"null pointer constant" (NPC). You might be forgiven for thinking it
should mean "a constant expression with pointer type and a null value" -
but the reality is that many constant expressions fail to qualify as
integer literals, and therefore fail to qualify as NPCs. Furthermore,
while an NPC implicitly converts to pointer types in many contexts, in
themselves they are prohibited from having pointer type.
You're free to refer to other possible meanings of the phrase "pure
virtual function", but in a C++ context you should always identify the
fact that you're not using the meaning for that term which is provided
by the C++ standard. To criticize someone for using the term in a C++
context with precisely the meaning described by the C++ standard for
that term, is to reject the whole point of having a standard.
bol...@cylonhq.com
Jun 29, 2018, 5:02:23 AM6/29/18
to
On Thu, 28 Jun 2018 16:58:47 +0100
>hominem remarks of that kind would just be an indication that you have
>lost the argument. So you seem not only to be lacking understanding
I haven't lost anything, you're just being defensive because you know you don't
have a leg to stand on as someone else has pointed out very eloquently. I'll
just settle for calling you an idiot.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>On Thu, 28 Jun 2018 15:34:15 +0000 (UTC)
>bol...@cylonHQ.com wrote:
>> On Thu, 28 Jun 2018 16:25:23 +0100
>> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>> >On Thu, 28 Jun 2018 15:06:27 +0000 (UTC)
>> >bol...@cylonHQ.com wrote:
>> >> In C++ that is the definition of pure. This discussion is about C++ not
>> >> the general definition of pure virtuals as you see it.
>> >
>> >Pure functions are rarely virtual. Anyone with minimal knowledge of
>> >computer science knows what a pure function is.
>>
>> We're not talking about the mathematical definition of pure, we're talking
>> about the c++ definition of pure virtuals which mean something else entirely.
>
>> Either you're being pedantic for the sake of it or you're just another
>> aspie unable to follow normal discussion.
>
>If I were, that would be a totally inappropriate remark to make. Ad
I couldn't care less and I think you are.
>On Thu, 28 Jun 2018 15:34:15 +0000 (UTC)
>bol...@cylonHQ.com wrote:
>> On Thu, 28 Jun 2018 16:25:23 +0100
>> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>> >On Thu, 28 Jun 2018 15:06:27 +0000 (UTC)
>> >bol...@cylonHQ.com wrote:
>> >> In C++ that is the definition of pure. This discussion is about C++ not
>> >> the general definition of pure virtuals as you see it.
>> >
>> >Pure functions are rarely virtual. Anyone with minimal knowledge of
>> >computer science knows what a pure function is.
>>
>> We're not talking about the mathematical definition of pure, we're talking
>> about the c++ definition of pure virtuals which mean something else entirely.
>
>> Either you're being pedantic for the sake of it or you're just another
>> aspie unable to follow normal discussion.
>
>If I were, that would be a totally inappropriate remark to make. Ad
>hominem remarks of that kind would just be an indication that you have
>lost the argument. So you seem not only to be lacking understanding
have a leg to stand on as someone else has pointed out very eloquently. I'll
just settle for calling you an idiot.
Chris Vine
Jun 29, 2018, 6:37:08 AM6/29/18
to
On Thu, 28 Jun 2018 20:49:27 -0700 (PDT)
james...@alumni.caltech.edu wrote:
> On Thursday, June 28, 2018 at 10:20:40 AM UTC-4, Chris Vine wrote:
> > On Thu, 28 Jun 2018 09:40:42 +0000 (UTC)
> > bol...@cylonHQ.com wrote:
> > > IMO the C++ syntax has now jumped the shark, its far to complex and rivals
> > > Perl in its hideousnous. Originally it was commented that uglies such as
> > > "virtual func() = 0" instead of "pure virtual func()" were because extra
> > > keywords may break older programs that use them as names elsewhere.
> >
> > A pure function means something completely different. That would be a
> > very poor choice of words, quite apart from needing a new keyword.
>
> We're talking about C++ here. The C++ standard defines what the term
> "pure virtual function" means in the context of C++ (10.4p2). Like many
> other pieces of C++ jargon, you can't interpret it correctly by
> interpreting it word for word according to the generally accepted
> meanings of those words - the only way to correctly understand what the
> phrase means in a C++ context is to read what the C++ standard says
> about such functions. That definition does not correspond to "a pure
> function in the mathematical sense which is also virtual".
My point was not that in C++ the expression "pure virtual function"
james...@alumni.caltech.edu wrote:
> On Thursday, June 28, 2018 at 10:20:40 AM UTC-4, Chris Vine wrote:
> > On Thu, 28 Jun 2018 09:40:42 +0000 (UTC)
> > bol...@cylonHQ.com wrote:
> > > IMO the C++ syntax has now jumped the shark, its far to complex and rivals
> > > Perl in its hideousnous. Originally it was commented that uglies such as
> > > "virtual func() = 0" instead of "pure virtual func()" were because extra
> > > keywords may break older programs that use them as names elsewhere.
> >
> > A pure function means something completely different. That would be a
> > very poor choice of words, quite apart from needing a new keyword.
>
> We're talking about C++ here. The C++ standard defines what the term
> "pure virtual function" means in the context of C++ (10.4p2). Like many
> other pieces of C++ jargon, you can't interpret it correctly by
> interpreting it word for word according to the generally accepted
> meanings of those words - the only way to correctly understand what the
> phrase means in a C++ context is to read what the C++ standard says
> about such functions. That definition does not correspond to "a pure
> function in the mathematical sense which is also virtual".
means a pure function which is also virtual. I know that in C++ "pure
virtual function" refers to a virtual function without implementation.
'pure' is not at present a keyword in C++. My point was that if C++ is
going to have a 'pure' keyword, then the keyword ought to be used to
denote a pure function in the computer science sense, and not used to
denote a C++ pure virtual function (in other words, it shouldn't be
used just to provide an alternative to writing '= 0'). Out of
interest, is this a view you actually disagree with?
On whether to have 'pure' as a keyword, that raises other issues. D
has one, rust has decided not to because rust's type system deals with
the issue in other ways. I would take the lead from compiler writers
and ask them whether the keyword would provide optimization
opportunities that would otherwise be difficult to apply.
james...@alumni.caltech.edu
Jun 29, 2018, 6:47:51 AM6/29/18
to
On Friday, June 29, 2018 at 6:37:08 AM UTC-4, Chris Vine wrote:
> On Thu, 28 Jun 2018 20:49:27 -0700 (PDT)
> james...@alumni.caltech.edu wrote:
...
> On Thu, 28 Jun 2018 20:49:27 -0700 (PDT)
> james...@alumni.caltech.edu wrote:
> > We're talking about C++ here. The C++ standard defines what the term
> > "pure virtual function" means in the context of C++ (10.4p2). Like many
> > other pieces of C++ jargon, you can't interpret it correctly by
> > interpreting it word for word according to the generally accepted
> > meanings of those words - the only way to correctly understand what the
> > phrase means in a C++ context is to read what the C++ standard says
> > about such functions. That definition does not correspond to "a pure
> > function in the mathematical sense which is also virtual".
>
> My point was not that in C++ the expression "pure virtual function"
> means a pure function which is also virtual. I know that in C++ "pure
> virtual function" refers to a virtual function without implementation.
>
> 'pure' is not at present a keyword in C++. My point was that if C++ is
> going to have a 'pure' keyword, then the keyword ought to be used to
> denote a pure function in the computer science sense, and not used to
> denote a C++ pure virtual function (in other words, it shouldn't be
> used just to provide an alternative to writing '= 0'). Out of
> interest, is this a view you actually disagree with?
Yes - since the C++ standard defines the meaning of "pure virtual
> > "pure virtual function" means in the context of C++ (10.4p2). Like many
> > other pieces of C++ jargon, you can't interpret it correctly by
> > interpreting it word for word according to the generally accepted
> > meanings of those words - the only way to correctly understand what the
> > phrase means in a C++ context is to read what the C++ standard says
> > about such functions. That definition does not correspond to "a pure
> > function in the mathematical sense which is also virtual".
>
> My point was not that in C++ the expression "pure virtual function"
> means a pure function which is also virtual. I know that in C++ "pure
> virtual function" refers to a virtual function without implementation.
>
> 'pure' is not at present a keyword in C++. My point was that if C++ is
> going to have a 'pure' keyword, then the keyword ought to be used to
> denote a pure function in the computer science sense, and not used to
> denote a C++ pure virtual function (in other words, it shouldn't be
> used just to provide an alternative to writing '= 0'). Out of
> interest, is this a view you actually disagree with?
function", then I think would be entirely appropriate for it to be
modified to use "pure" as a keyword for the purpose of making a virtual
function be a pure virtual function. I think that using "pure" with any
other meaning would be MORE confusing.
Convince the committee that it shouldn't have used the term "pure" for
this purpose, and they can change the standard to use some other
terminology, without breaking any existing code. Unless and until you
succeed in convincing them, them it would be reasonable for them to
define a "pure" keyword with that meaning; and reasonable to criticize
their decision to use "=0" instead.
Alf P. Steinbach
Jun 29, 2018, 4:33:28 PM6/29/18
to
On 29.06.2018 12:47, james...@alumni.caltech.edu wrote:
> [snip]
not to blame, they couldn't do a thing about it.
He wrote in evolution & design that it was meant to indicate no function
body.
That clashes a bit with modern C++ (possibly also the pre-standard ARM,
but my copy is not accessible to me now) where a pure virtual can have a
function body, just not in the declaration in the class.
Which is a strange inconsistency in the standard.
Anyway...
Cheers!,
- Alf
> [snip]
> terminology, without breaking any existing code. Unless and until you
> succeed in convincing them, them it would be reasonable for them to
> define a "pure" keyword with that meaning; and reasonable to criticize
> their decision to use "=0" instead.
The `=0` goes way back. It's Bjarne's work exclusively. The committee is
> succeed in convincing them, them it would be reasonable for them to
> define a "pure" keyword with that meaning; and reasonable to criticize
> their decision to use "=0" instead.
not to blame, they couldn't do a thing about it.
He wrote in evolution & design that it was meant to indicate no function
body.
That clashes a bit with modern C++ (possibly also the pre-standard ARM,
but my copy is not accessible to me now) where a pure virtual can have a
function body, just not in the declaration in the class.
Which is a strange inconsistency in the standard.
Anyway...
Cheers!,
- Alf
Vir Campestris
Jun 29, 2018, 4:33:58 PM6/29/18
to
On 29/06/2018 11:47, james...@alumni.caltech.edu wrote:
> Yes - since the C++ standard defines the meaning of "pure virtual
> function", then I think would be entirely appropriate for it to be
> modified to use "pure" as a keyword for the purpose of making a virtual
> function be a pure virtual function. I think that using "pure" with any
> other meaning would be MORE confusing.
> Convince the committee that it shouldn't have used the term "pure" for
> this purpose, and they can change the standard to use some other
> terminology, without breaking any existing code. Unless and until you
> succeed in convincing them, them it would be reasonable for them to
> define a "pure" keyword with that meaning; and reasonable to criticize
> their decision to use "=0" instead.
OK, so I'm not a mathematician - but I'm not aware of the use of pure in
> Yes - since the C++ standard defines the meaning of "pure virtual
> function", then I think would be entirely appropriate for it to be
> modified to use "pure" as a keyword for the purpose of making a virtual
> function be a pure virtual function. I think that using "pure" with any
> other meaning would be MORE confusing.
> Convince the committee that it shouldn't have used the term "pure" for
> this purpose, and they can change the standard to use some other
> terminology, without breaking any existing code. Unless and until you
> succeed in convincing them, them it would be reasonable for them to
> define a "pure" keyword with that meaning; and reasonable to criticize
> their decision to use "=0" instead.
maths. Chemistry, yes...
However if the intent is to replace
virtual foo function() = 0;
then shouldn't the syntax be
pure foo function();
You don't need to say it's virtual. It's implied - it cannot not be virtual.
Andy
Alf P. Steinbach
Jun 30, 2018, 1:34:00 AM6/30/18
to
other things. Therefore it doesn't imply "virtual".
Besides, it's the phrase "pure virtual" that has a special meaning.
Just "pure" means something else.
Cheers!,
- Alf
Öö Tiib
Jun 30, 2018, 6:14:17 AM6/30/18
to
not have side effects) but it has obscure keyword "constexpr" to
denote that.
Manfred
Jun 30, 2018, 10:38:15 AM6/30/18
to
the sense you mean), I think that the fact that constexpr functions
silently decay to non-constexpr when conditions are not met, deviates
from a specification of 'pure'.
I mean, I think that an hypothetical 'pure' keyword would /require/ the
function to have no side effects, instead of silently decaying to non-pure.
Chris Vine
Jun 30, 2018, 12:37:56 PM6/30/18
to
that are not literals), a constexpr function does not as far as I can
see decay to "non-pure". Rather it decays to evaluation at run time
instead of at compile time.
I think it probably follows, from the C++ specification for constexpr
functions, that they are pure. The feature of a constexpr function
however is that it will be executed at compile time if passed values
known at compile time. That is not a requirement for a pure function
(many can be evaluated at compile time when passed literal arguments,
but not all - see below).
The requirement of a pure function in a computer science sense is that
it has no side effects and does not depend on mutable state (either
global or as a closure). On the current C++ requirements for a
function to be constexpr, you can clearly have pure functions which do
not qualify as constexpr. There is nothing to stop a pure function
using 'goto' within its implementation for example, but if it does it
cannot be constexpr.
Probably the C++ specification for constexpr functions can be expanded
further to include other pure functions. However I doubt that the two
can be completely aligned. If there were to be a 'pure' keyword in
C++, it could for example cover functions depending on const static
state. This might be relevant to a function which depends on the
number of processors on the machine executing the program; such a
function could be "pure" (on any one run it always gives the same
outputs for the same inputs) but cannot be "constexpr".
Chris Vine
Jun 30, 2018, 12:56:52 PM6/30/18
to
On Sat, 30 Jun 2018 17:37:41 +0100
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
[snip]
memory (that is, which just make the program fail irrecoverably in the
event of the memory supply being exceeded, and do not throw exceptions
in that case) can nominate functions using, say, local string objects as
"pure", even where the string objects require dynamic memory. Such
functions could never be "constexpr" as the word is currently defined
in C++.
I suppose such points of detail come down to what the language decides
is "pure" in the context of whatever compiler optimizations it is
trying to support by adopting that keyword.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
[snip]
> Probably the C++ specification for constexpr functions can be expanded
> further to include other pure functions. However I doubt that the two
> can be completely aligned. If there were to be a 'pure' keyword in
> C++, it could for example cover functions depending on const static
> state. This might be relevant to a function which depends on the
> number of processors on the machine executing the program; such a
> function could be "pure" (on any one run it always gives the same
> outputs for the same inputs) but cannot be "constexpr".
Incidentally languages (or programs) which assume the availability of
> further to include other pure functions. However I doubt that the two
> can be completely aligned. If there were to be a 'pure' keyword in
> C++, it could for example cover functions depending on const static
> state. This might be relevant to a function which depends on the
> number of processors on the machine executing the program; such a
> function could be "pure" (on any one run it always gives the same
> outputs for the same inputs) but cannot be "constexpr".
memory (that is, which just make the program fail irrecoverably in the
event of the memory supply being exceeded, and do not throw exceptions
in that case) can nominate functions using, say, local string objects as
"pure", even where the string objects require dynamic memory. Such
functions could never be "constexpr" as the word is currently defined
in C++.
I suppose such points of detail come down to what the language decides
is "pure" in the context of whatever compiler optimizations it is
trying to support by adopting that keyword.
Tim Rentsch
Jun 30, 2018, 2:03:15 PM6/30/18
to
bol...@cylonHQ.com writes:
> On Wed, 27 Jun 2018 17:14:59 -0400
> Sam <s...@email-scan.com> wrote:
>
>> With the increased complexity of C++, only an actual C++ compiler can fully
>> understand C++ code. This is not the only part of modern C++ that doxygen
>> doesn't quite pick up.
>
> IMO the C++ syntax has now jumped the shark, [...]
> On Wed, 27 Jun 2018 17:14:59 -0400
> Sam <s...@email-scan.com> wrote:
>
>> With the increased complexity of C++, only an actual C++ compiler can fully
>> understand C++ code. This is not the only part of modern C++ that doxygen
>> doesn't quite pick up.
>
"jumped the shark". That's good. :)
Tim Rentsch
Jun 30, 2018, 2:37:23 PM6/30/18
to
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
> The requirement of a pure function in a computer science sense is
> that it has no side effects and does not depend on mutable state
> (either global or as a closure).
I think you are confusing the notions of "pure" and "referentially
> The requirement of a pure function in a computer science sense is
> that it has no side effects and does not depend on mutable state
> (either global or as a closure).
transparent":
https://en.wikipedia.org/wiki/Pure_function
https://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29
The following function is pure:
static int jiggery_pokery;
int
ivory( int a ){
return a + jiggery_pokery;
}
but a call to ivory() it is (very probably) not referentially
transparent.
> I think it probably follows, from the C++ specification for
> constexpr functions, that they are pure.
argument values:
constexpr int
foo( int x, int bar( int ) ){
return bar( x );
}
constexpr int
pure( int x ){
return x;
}
int
impure( int x ){
static int z;
return x + z++;
}
constexpr int three = foo( 3, pure );
#include <iostream>
int
main(){
const int a = foo( 3, impure );
const int b = foo( 3, impure );
const int c = foo( 3, impure );
std::cout << ' ' << a << ' ' << b << ' ' << c << '\n';
}
Tim Rentsch
Jun 30, 2018, 2:41:47 PM6/30/18
to
and a pure function is not necessarily one that can be made
constexpr. See my response to Chris Vine's post downthread.
Tim Rentsch
Jun 30, 2018, 2:44:25 PM6/30/18
to
"Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
> On 29.06.2018 22:33, Vir Campestris wrote:
>
>> On 29/06/2018 11:47, james...@alumni.caltech.edu wrote:
>>
>>> Yes - since the C++ standard defines the meaning of "pure virtual
>>> function", then I think would be entirely appropriate for it to be
>>> modified to use "pure" as a keyword for the purpose of making a virtual
>>> function be a pure virtual function. I think that using "pure" with any
>>> other meaning would be MORE confusing.
>>> Convince the committee that it shouldn't have used the term "pure" for
>>> this purpose, and they can change the standard to use some other
>>> terminology, without breaking any existing code. Unless and until you
>>> succeed in convincing them, them it would be reasonable for them to
>>> define a "pure" keyword with that meaning; and reasonable to criticize
>>> their decision to use "=0" instead.
>>
>> OK, so I'm not a mathematician - but I'm not aware of the use of
>> pure in maths. Chemistry, yes...
>>
>> However if the intent is to replace
>>
>> virtual foo function() = 0;
>>
>> then shouldn't the syntax be
>>
>> pure foo function();
>>
>> You don't need to say it's virtual. It's implied - it cannot not be
>> virtual.
>
> No, "pure" is an adjective applied to "virtual".
Actually, since it modifies "virtual" which is an adjective, in
> On 29.06.2018 22:33, Vir Campestris wrote:
>
>> On 29/06/2018 11:47, james...@alumni.caltech.edu wrote:
>>
>>> Yes - since the C++ standard defines the meaning of "pure virtual
>>> function", then I think would be entirely appropriate for it to be
>>> modified to use "pure" as a keyword for the purpose of making a virtual
>>> function be a pure virtual function. I think that using "pure" with any
>>> other meaning would be MORE confusing.
>>> Convince the committee that it shouldn't have used the term "pure" for
>>> this purpose, and they can change the standard to use some other
>>> terminology, without breaking any existing code. Unless and until you
>>> succeed in convincing them, them it would be reasonable for them to
>>> define a "pure" keyword with that meaning; and reasonable to criticize
>>> their decision to use "=0" instead.
>>
>> OK, so I'm not a mathematician - but I'm not aware of the use of
>> pure in maths. Chemistry, yes...
>>
>> However if the intent is to replace
>>
>> virtual foo function() = 0;
>>
>> then shouldn't the syntax be
>>
>> pure foo function();
>>
>> You don't need to say it's virtual. It's implied - it cannot not be
>> virtual.
>
> No, "pure" is an adjective applied to "virtual".
this setting "pure" is an adverb. (Forgive me, I was raised by
a grammarian.)
> It can be applied to
> other things. Therefore it doesn't imply "virtual".
>
> Besides, it's the phrase "pure virtual" that has a special meaning.
>
> Just "pure" means something else.
Alf P. Steinbach
Jun 30, 2018, 3:28:14 PM6/30/18
to
>> It can be applied to
>> other things. Therefore it doesn't imply "virtual".
>>
>> Besides, it's the phrase "pure virtual" that has a special meaning.
>>
>> Just "pure" means something else.
>
> All of this I agree with.
_ Alf
Manfred
Jun 30, 2018, 3:47:30 PM6/30/18
to
On 6/30/2018 6:37 PM, Chris Vine wrote:
>> I mean, I think that an hypothetical 'pure' keyword would/require/ the
diagnostic required".
I guess the case of having side effects qualifies as not a "core
constant expression" which in n4659 10.1.5 p5 results in an ill-formed
program, without warning (I hate those)
>> I mean, I think that an hypothetical 'pure' keyword would/require/ the
>> function to have no side effects, instead of silently decaying to non-pure.
> When called with arguments known only at run time (that is, with values
> that are not literals), a constexpr function does not as far as I can
> see decay to "non-pure". Rather it decays to evaluation at run time
> instead of at compile time.
OK, I fell in one of those traps where "the program is ill-formed, no
> When called with arguments known only at run time (that is, with values
> that are not literals), a constexpr function does not as far as I can
> see decay to "non-pure". Rather it decays to evaluation at run time
> instead of at compile time.
diagnostic required".
I guess the case of having side effects qualifies as not a "core
constant expression" which in n4659 10.1.5 p5 results in an ill-formed
program, without warning (I hate those)
Chris Vine
Jun 30, 2018, 4:25:41 PM6/30/18
to
On Sat, 30 Jun 2018 11:37:12 -0700
Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
> > The requirement of a pure function in a computer science sense is
> > that it has no side effects and does not depend on mutable state
> > (either global or as a closure).
>
> I think you are confusing the notions of "pure" and "referentially
> transparent":
>
> https://en.wikipedia.org/wiki/Pure_function
> https://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29
>
> The following function is pure:
>
> static int jiggery_pokery;
>
> int
> ivory( int a ){
> return a + jiggery_pokery;
> }
>
> but a call to ivory() it is (very probably) not referentially
> transparent.
The wikipedia article on pure functions is weak on its sources[1]. The
Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
> > The requirement of a pure function in a computer science sense is
> > that it has no side effects and does not depend on mutable state
> > (either global or as a closure).
>
> I think you are confusing the notions of "pure" and "referentially
> transparent":
>
> https://en.wikipedia.org/wiki/Pure_function
> https://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29
>
> The following function is pure:
>
> static int jiggery_pokery;
>
> int
> ivory( int a ){
> return a + jiggery_pokery;
> }
>
> but a call to ivory() it is (very probably) not referentially
> transparent.
only reference supporting the proposition that a 'pure function' can
access external _mutable_ state appears to be in relation to the gcc
'pure' attribute. That can mean what gcc want it to mean, possibly
aided by the fact that it has a separate 'const' attribute which means
what I say 'pure' means except that (i) it seems 'const' functions
cannot read _immutable_ globals, and (ii) the description of the
'const' attribute doesn't seem to say anything about non-global
external mutable data (although the explanation implies that accessing
that is disallowed). (Note for other readers: the gcc 'const' function
attribute has nothing to do with the 'const' keyword in C and C++.)
In D at least, the pure keyword precludes reading from or writing to
any global or static mutable state. That is, I would suggest, the
word's more common usage. However, D does allow pure functions
amongst other things to throw exceptions "as a concession to
practicality".
This perhaps comes back to the point that the language in question will
decide what is "pure" in the context of whatever compiler optimizations
it is trying to support by adopting that keyword.
> > I think it probably follows, from the C++ specification for
> > constexpr functions, that they are pure.
>
> They might be but don't have to be, depending on the particular
> argument values:
>
> constexpr int
> foo( int x, int bar( int ) ){
> return bar( x );
> }
>
> constexpr int
> pure( int x ){
> return x;
> }
>
> int
> impure( int x ){
> static int z;
> return x + z++;
> }
>
> constexpr int three = foo( 3, pure );
>
> #include <iostream>
>
> int
> main(){
> const int a = foo( 3, impure );
> const int b = foo( 3, impure );
> const int c = foo( 3, impure );
> std::cout << ' ' << a << ' ' << b << ' ' << c << '\n';
> }
Kudos: very clever. I am astonished that constexpr functions can take a
> > constexpr functions, that they are pure.
>
> They might be but don't have to be, depending on the particular
> argument values:
>
> constexpr int
> foo( int x, int bar( int ) ){
> return bar( x );
> }
>
> constexpr int
> pure( int x ){
> return x;
> }
>
> int
> impure( int x ){
> static int z;
> return x + z++;
> }
>
> constexpr int three = foo( 3, pure );
>
> #include <iostream>
>
> int
> main(){
> const int a = foo( 3, impure );
> const int b = foo( 3, impure );
> const int c = foo( 3, impure );
> std::cout << ' ' << a << ' ' << b << ' ' << c << '\n';
> }
reference to a non-constexpr function as an argument and then call it.
The values of 'a', 'b' and 'c' presumably are not computed at compile
time because the argument passed to 'bar' ('impure') is not constexpr.
This does appear to be a hole in the C++ language specification. I can
sort-of see the justification for it - the argument passed to 'bar'
might, or might not, be constexpr, and when it is then 'foo' is (as
required) called at compile time, as when initializing 'three'. But it
seems perverse.
Chris
[1] The 'Talk' page also inspires little confidence.
Christian Gollwitzer
Jun 30, 2018, 4:49:24 PM6/30/18
to
Am 30.06.18 um 20:44 schrieb Tim Rentsch:
should be a "purely virtual function" then, which makes a lot of sense,
other than a "pure virtual function" which is pure and a virtual
function - but I'm not a native speaker.
In any case I think that "pure" is a bad choice for both meanings
discussed here, because it is too unspecific. If I'd start over, I'd
call the "=0"-thingy a "placeholder", i.e.
placeholder int member();
and a "pure" function "side-effect free" function or simply "function",
whereas the thingy with side-effects could be a "procedure" or
"subroutine".
Christian
>>
>> No, "pure" is an adjective applied to "virtual".
>
> Actually, since it modifies "virtual" which is an adjective, in
> this setting "pure" is an adverb. (Forgive me, I was raised by
> a grammarian.)
And that's why I'm confused about it, my English sense tells me that it
>> No, "pure" is an adjective applied to "virtual".
>
> Actually, since it modifies "virtual" which is an adjective, in
> this setting "pure" is an adverb. (Forgive me, I was raised by
> a grammarian.)
should be a "purely virtual function" then, which makes a lot of sense,
other than a "pure virtual function" which is pure and a virtual
function - but I'm not a native speaker.
In any case I think that "pure" is a bad choice for both meanings
discussed here, because it is too unspecific. If I'd start over, I'd
call the "=0"-thingy a "placeholder", i.e.
placeholder int member();
and a "pure" function "side-effect free" function or simply "function",
whereas the thingy with side-effects could be a "procedure" or
"subroutine".
Christian
Chris M. Thomasson
Jul 1, 2018, 3:45:45 AM7/1/18
to
On 6/27/2018 2:37 PM, Chris M. Thomasson wrote:
> On 6/27/2018 2:34 PM, Paavo Helde wrote:
>> On 27.06.2018 23:29, Stefan Ram wrote:
>>> Tools like Doxygen copy the head of a function definition
>>> to double as documentation:
>>>
>>> Synopsis
>>> int f();
>>>
>>> , and, of course, the "Synopsis" gives us the return type.
>>>
>>> But what about a function definition like:
>>>
>>> auto f(){ return 7; }
>>>
>>> ? A synopsis like
>>>
>>> Synopsis
>>> auto f();
>>>
>>> is hardly helpful. So should we avoid the auto return type
>>> for functions which are part of an API for this reason?
>>
>> Nope, the tools should be updated to cope with the new language rules.
>>
>> However, auto return type should be avoided in API-s
>
> Agreed.
The return value of a function in an API exported from a shared lib, say
DLL or .so, must be concrete? This is what I am talking about wrt API.
Not a C++ header wrt API that can contain all sorts of fancy things...
;^)
>
>
>> because an API ought to define an interface (that's the I) but auto
>> depends on the implementation details. With something having an
>> official API it should be vice versa, implementation should depend on
>> the interface.
>
>
>
> On 6/27/2018 2:34 PM, Paavo Helde wrote:
>> On 27.06.2018 23:29, Stefan Ram wrote:
>>> Tools like Doxygen copy the head of a function definition
>>> to double as documentation:
>>>
>>> Synopsis
>>> int f();
>>>
>>> , and, of course, the "Synopsis" gives us the return type.
>>>
>>> But what about a function definition like:
>>>
>>> auto f(){ return 7; }
>>>
>>> ? A synopsis like
>>>
>>> Synopsis
>>> auto f();
>>>
>>> is hardly helpful. So should we avoid the auto return type
>>> for functions which are part of an API for this reason?
>>
>> Nope, the tools should be updated to cope with the new language rules.
>>
>> However, auto return type should be avoided in API-s
>
> Agreed.
The return value of a function in an API exported from a shared lib, say
DLL or .so, must be concrete? This is what I am talking about wrt API.
Not a C++ header wrt API that can contain all sorts of fancy things...
;^)
>
>
>> because an API ought to define an interface (that's the I) but auto
>> depends on the implementation details. With something having an
>> official API it should be vice versa, implementation should depend on
>> the interface.
>
>
>
Tim Rentsch
Jul 1, 2018, 9:55:18 AM7/1/18
to
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
> On Sat, 30 Jun 2018 11:37:12 -0700
> Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
>> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
>>
>>> The requirement of a pure function in a computer science sense is
>>> that it has no side effects and does not depend on mutable state
>>> (either global or as a closure).
>>
>> I think you are confusing the notions of "pure" and "referentially
>> transparent":
>>
>> https://en.wikipedia.org/wiki/Pure_function
>> https://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29
>>
>> The following function is pure:
>>
>> static int jiggery_pokery;
>>
>> int
>> ivory( int a ){
>> return a + jiggery_pokery;
>> }
>>
>> but a call to ivory() it is (very probably) not referentially
>> transparent.
>
> The wikipedia article on pure functions is weak on its sources.
> On Sat, 30 Jun 2018 11:37:12 -0700
> Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
>> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
>>
>>> The requirement of a pure function in a computer science sense is
>>> that it has no side effects and does not depend on mutable state
>>> (either global or as a closure).
>>
>> I think you are confusing the notions of "pure" and "referentially
>> transparent":
>>
>> https://en.wikipedia.org/wiki/Pure_function
>> https://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29
>>
>> The following function is pure:
>>
>> static int jiggery_pokery;
>>
>> int
>> ivory( int a ){
>> return a + jiggery_pokery;
>> }
>>
>> but a call to ivory() it is (very probably) not referentially
>> transparent.
>
> The only reference supporting the proposition that a 'pure function'
> can access external _mutable_ state appears to be in relation to the
> gcc 'pure' attribute. That can mean what gcc want it to mean,
> possibly aided by the fact that it has a separate 'const' attribute
> which means what I say 'pure' means except that (i) it seems 'const'
> functions cannot read _immutable_ globals, and (ii) the description
> of the 'const' attribute doesn't seem to say anything about
> non-global external mutable data (although the explanation implies
> that accessing that is disallowed). (Note for other readers: the
> gcc 'const' function attribute has nothing to do with the 'const'
> keyword in C and C++.)
>
> In D at least, the pure keyword precludes reading from or writing to
> any global or static mutable state. That is, I would suggest, the
> word's more common usage. However, D does allow pure functions
> amongst other things to throw exceptions "as a concession to
> practicality".
>
> This perhaps comes back to the point that the language in question
> will decide what is "pure" in the context of whatever compiler
> optimizations it is trying to support by adopting that keyword.
My impression is that "pure" in the sense of "not having side
> can access external _mutable_ state appears to be in relation to the
> gcc 'pure' attribute. That can mean what gcc want it to mean,
> possibly aided by the fact that it has a separate 'const' attribute
> which means what I say 'pure' means except that (i) it seems 'const'
> functions cannot read _immutable_ globals, and (ii) the description
> of the 'const' attribute doesn't seem to say anything about
> non-global external mutable data (although the explanation implies
> that accessing that is disallowed). (Note for other readers: the
> gcc 'const' function attribute has nothing to do with the 'const'
> keyword in C and C++.)
>
> In D at least, the pure keyword precludes reading from or writing to
> any global or static mutable state. That is, I would suggest, the
> word's more common usage. However, D does allow pure functions
> amongst other things to throw exceptions "as a concession to
> practicality".
>
> This perhaps comes back to the point that the language in question
> will decide what is "pure" in the context of whatever compiler
> optimizations it is trying to support by adopting that keyword.
effects" is more common and more usual in the general programming
community. It aligns with usage in the functional programming
community, where language features are described as "pure" or
"impure" according to whether side-effects may occur. It's
consistent with my memory of learning to distinguish pure Lisp,
"sometimes humorously referred to as poor Lisp" (admittedly not a
very reliable data point). Furthermore the property of being
side-effect free (but possibly accessing state that is otherwise
mutable) is a useful distinction to make, both for operators and
functions, because a set of such operations may be arbitrarily
reordered without changing the meaning, regardless of whether
mutable state is accessed. These items plus the existence of the
term "referentially transparent", which unambiguously has the
stronger meaning, lead me to think it is better to use "pure"
to mean just side-effect free, and "referentially transparent"
for the stronger meaning. In any case it seems best to limit
"pure" to mean no more than one of those two meanings, and not
add another definition which would further confuse the issue.
>>> I think it probably follows, from the C++ specification for
>>> constexpr functions, that they are pure.
>>
>> They might be but don't have to be, depending on the particular
>> argument values:
>>
>> constexpr int
>> foo( int x, int bar( int ) ){
>> return bar( x );
>> }
>>
>> constexpr int
>> pure( int x ){
>> return x;
>> }
>>
>> int
>> impure( int x ){
>> static int z;
>> return x + z++;
>> }
>>
>> constexpr int three = foo( 3, pure );
>>
>> #include <iostream>
>>
>> int
>> main(){
>> const int a = foo( 3, impure );
>> const int b = foo( 3, impure );
>> const int c = foo( 3, impure );
>> std::cout << ' ' << a << ' ' << b << ' ' << c << '\n';
>> }
>
> Kudos: very clever. I am astonished that constexpr functions can take a
> reference to a non-constexpr function as an argument and then call it.
goes. For myself, I wasn't sure when I tried it that it would
work, but I wasn't surprised when it did; I would have been more
surprised if it didn't.
> The values of 'a', 'b' and 'c' presumably are not computed at compile
> time because the argument passed to 'bar' ('impure') is not constexpr.
compiler can see all the places 'impure' is used, and figure
things out in advance. But neither g++ nor clang was smart
enough to do so, and certainly it cannot be done in general.
> This does appear to be a hole in the C++ language specification. I can
> sort-of see the justification for it - the argument passed to 'bar'
> might, or might not, be constexpr, and when it is then 'foo' is (as
> required) called at compile time, as when initializing 'three'. But it
> seems perverse.
just a regular function, except with certain restrictions that
guarantee it can be evaluated at compile time, _provided_ certain
things are true of the arguments given. But if the return value
doesn't need to be constexpr, a constexpr function can be used
just like a regular function[*]. I see this quality as a
strength, not a weakness.
[*] Disclaimer: I believe. I find the C++ standard very hard
reading, and in this case I didn't even try to read what it
requires in such cases.
Tim Rentsch
Jul 1, 2018, 11:12:14 AM7/1/18
to
Christian Gollwitzer <auri...@gmx.de> writes:
> Am 30.06.18 um 20:44 schrieb Tim Rentsch:
>
>>> No, "pure" is an adjective applied to "virtual".
>>
>> Actually, since it modifies "virtual" which is an adjective, in
>> this setting "pure" is an adverb. (Forgive me, I was raised by
>> a grammarian.)
>
> And that's why I'm confused about it, my English sense tells me that
> it should be a "purely virtual function" then, which makes a lot of
> sense, other than a "pure virtual function" which is pure and a
> virtual function - but I'm not a native speaker.
To some extent I share your reaction. I wouldn't use "purely
> Am 30.06.18 um 20:44 schrieb Tim Rentsch:
>
>>> No, "pure" is an adjective applied to "virtual".
>>
>> Actually, since it modifies "virtual" which is an adjective, in
>> this setting "pure" is an adverb. (Forgive me, I was raised by
>> a grammarian.)
>
> And that's why I'm confused about it, my English sense tells me that
> it should be a "purely virtual function" then, which makes a lot of
> sense, other than a "pure virtual function" which is pure and a
> virtual function - but I'm not a native speaker.
virtual function" (although I did think of it), because it
somehow doesn't mean the right thing, even if I'm not sure of
exactly what it does or should mean.
So, on further reflection, I think a different characterization is
probably more appropriate here. Rather than thinking of "pure" as
modifying "virtual" (surely "pure" is not meant to modify the word
"function"?), suppose we think of "virtual function" as a compound
noun, so "pure virtual function" should be read as if it were
"pure (virtual function)", rather than "pure, virtual function",
which would mean a function that is both pure and virtual. The
compound noun idea is a little better, but still seems a bit off.
What I think is better is to take "pure virtual" as a compound
/adjective/, making a new meaning for the combination; that would
mean "pure virtual function" should be read as "(pure virtual)
function". In many cases compound adjectives are hyphenated, but
not always, and here I think it reads better without a hyphen.
Also I think "(pure virtual) function" is how most C++-ers think
of the term.
> In any case I think that "pure" is a bad choice for both meanings
> discussed here, because it is too unspecific. If I'd start over, I'd
> call the "=0"-thingy a "placeholder", i.e.
>
> placeholder int member();
>
> and a "pure" function "side-effect free" function or simply
> "function", whereas the thingy with side-effects could be a
> "procedure" or "subroutine".
(rather than some symbolic syntax) kind of as much as possible.
Personally I think that's a bad trend. I would rather see just
int member() = 0;
to mean a (pure virtual) function. As someone pointed out, the
'=0' makes 'virtual' redundant, so why not just leave it off?
(Or maybe leaving it off could be optional.) Notation helps.
For centuries mathematicians wrote without symbols, just in
ordinary language. That would be unthinkable today, and IMO
rightly so. Or, take another example, the physical laws for
electromagnetic fields. When Maxwell orginally wrote his famous
equations, there were not four equations but sixteen equations,
because vector notation hadn't been invented yet. No one would
consider doing that today. So it seems rather strange to see
programming languages embracing a more verbal (and more verbose)
form of expression.
Chris Vine
Jul 2, 2018, 5:44:12 AM7/2/18
to
On Sun, 01 Jul 2018 06:55:06 -0700
Tim Rentsch <t...@alumni.caltech.edu> wrote:
[snip]
one should call it "brutally pure") is referentially transparent. What
we are talking about is what it means for a function to be 'pure' in an
impure language (a language which does have side effects, including
mutable global state). Most people would say the word 'pure' has
something to do with the notion of a mathematical function, where
mutable global state has no meaning. So I think this is a point on
which we are going to have to agree to disagree about what is the
common understanding, which is in any event a matter of opinion.
On a differnet point, we were talking about C++ keywords and I don't
think you can really have a keyword as long as
"referentially_transparent". "Pure" is short and snappy and does the
business in my view, and is malleable enough to mean what you have
decided you need it to mean. At least two people think that another
name should be chosen because "pure" is already taken in C++, in the
expression "pure virtual function".
Anyway, you have proved that constexpr functions if called without
constexpr arguments may be impure on any view of what it means
for a function to be 'pure'. I am disappointed but on that point duly
enlightened.
Tim Rentsch <t...@alumni.caltech.edu> wrote:
[snip]
> My impression is that "pure" in the sense of "not having side
> effects" is more common and more usual in the general programming
> community. It aligns with usage in the functional programming
> community, where language features are described as "pure" or
> "impure" according to whether side-effects may occur. It's
> consistent with my memory of learning to distinguish pure Lisp,
> "sometimes humorously referred to as poor Lisp" (admittedly not a
> very reliable data point). Furthermore the property of being
> side-effect free (but possibly accessing state that is otherwise
> mutable) is a useful distinction to make, both for operators and
> functions, because a set of such operations may be arbitrarily
> reordered without changing the meaning, regardless of whether
> mutable state is accessed. These items plus the existence of the
> term "referentially transparent", which unambiguously has the
> stronger meaning, lead me to think it is better to use "pure"
> to mean just side-effect free, and "referentially transparent"
> for the stronger meaning. In any case it seems best to limit
> "pure" to mean no more than one of those two meanings, and not
> add another definition which would further confuse the issue.
Well, any wholly 'pure' programming language such as Haskell (perhaps
> effects" is more common and more usual in the general programming
> community. It aligns with usage in the functional programming
> community, where language features are described as "pure" or
> "impure" according to whether side-effects may occur. It's
> consistent with my memory of learning to distinguish pure Lisp,
> "sometimes humorously referred to as poor Lisp" (admittedly not a
> very reliable data point). Furthermore the property of being
> side-effect free (but possibly accessing state that is otherwise
> mutable) is a useful distinction to make, both for operators and
> functions, because a set of such operations may be arbitrarily
> reordered without changing the meaning, regardless of whether
> mutable state is accessed. These items plus the existence of the
> term "referentially transparent", which unambiguously has the
> stronger meaning, lead me to think it is better to use "pure"
> to mean just side-effect free, and "referentially transparent"
> for the stronger meaning. In any case it seems best to limit
> "pure" to mean no more than one of those two meanings, and not
> add another definition which would further confuse the issue.
one should call it "brutally pure") is referentially transparent. What
we are talking about is what it means for a function to be 'pure' in an
impure language (a language which does have side effects, including
mutable global state). Most people would say the word 'pure' has
something to do with the notion of a mathematical function, where
mutable global state has no meaning. So I think this is a point on
which we are going to have to agree to disagree about what is the
common understanding, which is in any event a matter of opinion.
On a differnet point, we were talking about C++ keywords and I don't
think you can really have a keyword as long as
"referentially_transparent". "Pure" is short and snappy and does the
business in my view, and is malleable enough to mean what you have
decided you need it to mean. At least two people think that another
name should be chosen because "pure" is already taken in C++, in the
expression "pure virtual function".
Anyway, you have proved that constexpr functions if called without
constexpr arguments may be impure on any view of what it means
for a function to be 'pure'. I am disappointed but on that point duly
enlightened.
Vir Campestris
Jul 2, 2018, 1:40:46 PM7/2/18
to
On 30/06/2018 06:33, Alf P. Steinbach wrote:
> On 29.06.2018 22:33, Vir Campestris wrote:
<SNIP>
> On 29.06.2018 22:33, Vir Campestris wrote:
>> OK, so I'm not a mathematician - but I'm not aware of the use of pure
>> in maths. Chemistry, yes...
>>
>> However if the intent is to replace
>>
>> virtual foo function() = 0;
>>
>> then shouldn't the syntax be
>>
>> pure foo function();
>>
>> You don't need to say it's virtual. It's implied - it cannot not be
>> virtual.
>
> No, "pure" is an adjective applied to "virtual". It can be applied to
> other things. Therefore it doesn't imply "virtual".
>
> Besides, it's the phrase "pure virtual" that has a special meaning.
>
> Just "pure" means something else.
I just checked. Currently in C++ pure is an identifier, not a keyword.
>> in maths. Chemistry, yes...
>>
>> However if the intent is to replace
>>
>> virtual foo function() = 0;
>>
>> then shouldn't the syntax be
>>
>> pure foo function();
>>
>> You don't need to say it's virtual. It's implied - it cannot not be
>> virtual.
>
> No, "pure" is an adjective applied to "virtual". It can be applied to
> other things. Therefore it doesn't imply "virtual".
>
> Besides, it's the phrase "pure virtual" that has a special meaning.
>
> Just "pure" means something else.
If we added a "pure" keyword, all those with variables/functions named
pure would of course scream - but what other uses do you see it having?
(I've just been reading around. It looks as though pure has established
meanings in other languages, and they aren't all the same :( so I think
I'd like to keep =0; - although as has been pointed out, virtual isn't
needed there either)
Andy
Tim Rentsch
Jul 12, 2018, 11:44:52 PM7/12/18
to
On the other hand, there is evidence for my earlier statement, in
the form of statements in the Wikipedia article (which presumably
has been read by thousands of people), and in the literature
discussing various functional languages. Some might say these
things are rather weak or indirect evidence, and I won't argue
with that, but they are still _some_ evidence. I still don't see
that any evidence has been presented for your position.
> So I think this is a point on
> which we are going to have to agree to disagree about what is the
> common understanding, which is in any event a matter of opinion.
opinion. It isn't feasible to verify which one is the case, but
in principle an answer can be objectively determined just by
polling the appropriate audience set about what their views are.
That makes the matter a question of fact.
Note by the way that my statement was made for the set of people
"in the general programming community."
> On a differnet point, we were talking about C++ keywords and I don't
> think you can really have a keyword as long as
> "referentially_transparent". "Pure" is short and snappy and does the
> business in my view, and is malleable enough to mean what you have
> decided you need it to mean.
I am opposed on principle to bending the meaning of words to fit
> think you can really have a keyword as long as
> "referentially_transparent". "Pure" is short and snappy and does the
> business in my view, and is malleable enough to mean what you have
> decided you need it to mean.
incongruous situations just because the word happens to be short
or in some other way convenient. Moreover the word "pure" isn't
really very descriptive of what's going on, ie, for functions
that don't depend on the outside environment. A better term
might be "self-contained", or if we really need a shorter word,
"closed".
> At least two people think that another name should be chosen
> because "pure" is already taken in C++, in the expression "pure
> virtual function".
compound adjective followed by a noun; that is, not "pure,
virtual function", but instead "(pure virtual) function".
So that may not impinge on what "pure" means by itself.
> Anyway, you have proved that constexpr functions if called without
> constexpr arguments may be impure on any view of what it means
> for a function to be 'pure'. I am disappointed but on that point duly
> enlightened.
because it shows that what "constexpr" means cuts across other
function-classification terms, and so it deserves its own name.
Tim Rentsch
Jul 18, 2018, 3:47:39 AM7/18/18
to
if the function cannot possibly be called to deliver a constexpr
result. As long as there is some way of calling it to deliver a
constexpr result, it's okay to call it other ways that result in
runtime evaluation. Yes?
0 new messages