Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #67159 > unrolled thread

2020 C++

Back to article view | Back to comp.lang.c++

Contents

  2020 C++ woodbrian77@gmail.com - 2019-07-24 19:10 -0700
    Re: 2020 C++ "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-25 04:45 +0200
      Re: 2020 C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-25 10:25 +0200
      Re: 2020 C++ Juha Nieminen <nospam@thanks.invalid> - 2019-07-25 08:40 +0000
      Re: 2020 C++ woodbrian77@gmail.com - 2019-07-25 07:49 -0700
        Re: 2020 C++ David Brown <david.brown@hesbynett.no> - 2019-07-25 19:13 +0200
      Re: 2020 C++ JiiPee <no@notvalid.com> - 2019-08-07 13:10 +0100
    Re: 2020 C++ David Brown <david.brown@hesbynett.no> - 2019-07-25 10:05 +0200
      Re: 2020 C++ "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-25 10:14 +0200
        Re: 2020 C++ David Brown <david.brown@hesbynett.no> - 2019-07-25 10:48 +0200
          Re: 2020 C++ Bo Persson <bo@bo-persson.se> - 2019-07-25 11:22 +0200
            Re: 2020 C++ David Brown <david.brown@hesbynett.no> - 2019-07-25 12:28 +0200
              Re: 2020 C++ lightness1024@gmail.com - 2019-07-25 03:57 -0700
              Re: 2020 C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-07-25 14:16 +0000
                Re: 2020 C++ David Brown <david.brown@hesbynett.no> - 2019-07-25 19:19 +0200
              Re: 2020 C++ Manfred <noname@add.invalid> - 2019-07-25 20:53 +0200
                Re: 2020 C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-06 09:31 -0700
                  Re: 2020 C++ Fran <flitterio@gmail.com> - 2019-08-06 16:05 -0400
                    Re: 2020 C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-09 10:44 -0700

#67159 — 2020 C++

B"H

So far the only thing I've found in 2020 C++ that seems 
helpful to me is std::span.  I posted a question about coroutines:
https://www.reddit.com/r/cpp_questions/comments/c6mbls/coroutines/

and that didn't seem like a fruitful avenue.  What am I
missing?  Thanks in advance.


Brian
Ebenezer Enterprises - Enjoying programming again.
https://github.com/Ebenezer-group/onwards

[toc] | [next] | [standalone]

#67160

On 25.07.2019 04:10, woodbrian77@gmail.com wrote:
> B"H
> 
> So far the only thing I've found in 2020 C++ that seems
> helpful to me is std::span.  I posted a question about coroutines:
> https://www.reddit.com/r/cpp_questions/comments/c6mbls/coroutines/
> 
> and that didn't seem like a fruitful avenue.  What am I
> missing?  Thanks in advance.

There's the math constants, finally an official standard library pi! :)

And there's the format library, <url: 
http://www.zverovich.net/2019/07/23/std-format-cpp20.html>.

Designated initializers for structs.

The spaceship operator (more full fledged support for functionality like 
`memcmp` and `std::basic_string::compare`).

Calendar functionality in <chrono>.

Ranges (but while most everybody's happy with that I think that library 
gives verbose and impenetrable source code and adds inefficiency, and 
constitutes yet another large sub-language - I much prefer my own simple 
`up_to(n)` to the Ranges library's x times renamed unnatural something).

Coroutines.

Modules!

But while I very much want modules I'm not so happy to get them in 
C++20. I think the modules thing is very much premature. Until they've 
got Boost expressed as modules there's no relevant real world 
experience, and the fact that they don't indicates it's not good enough.

Cheers!,

- Alf

[toc] | [prev] | [next] | [standalone]

#67163

> There's the math constants, finally an official standard library pi! :)

Hopefully it will be declared as a binary / hex floating point value
and not decimal in the headers.

[toc] | [prev] | [next] | [standalone]

#67164

Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
> Designated initializers for structs.

It's very disappointing to me that in C++20 designated initializers
need to be listed in the same order as they appear in the struct
declaration.

Having programmed quite a lot in (Apple's) Objective-C++, I just love
how it beautifully and superbly mixes C99 designated initializers with
C++ struct member default values. In other words, things like this are
possible:

    struct S { int a = 1, b = 2, c = 3; };

    const S s = { .c = 10, .a = 20 };

After this, s.a == 20, s.b == 2, and s.c == 10.

I have found this feature extremely useful because it allows creating
eg. (const-type) "settings" listings that are easy to read and modify,
of the type like:

    const Settings kSettings =
    {
        .amountOfThings = 20,
	.anotherAmount = 35,
	.aListOfValues = { 2, 4, 6, 10 },
	.someName = "hello there"
	.aBlockOfSubValues =
	{
	    .firstSubValue = 5,
	    .secondSubValue = 10
	}
    };

Not all members need to be specifically included in this initialization,
as they can have default values, and the order in which the elements
are listed is free.

The above is impossible both in C and C++. It's only possible in (Apple's)
Objective-C++. With C++20 it will become possible... except for the
"wrong" order of initialization, as the above will be required to instead
be:

    const S s = { .a = 20, .c = 10 };

This means that you can't list the elements in any order you want. This
can be a bit of a hindrance. The members of the struct itself might be
in a less-than-logical order for example for optimization reasons (the
size of a struct can be affected by the order in which the member
variables are listed), but in an initialization like above they can be
listed in a more logical order, grouping related settings together.

I understand why C++20 will require the initializers to be listed in the
same order as the declaration, but I still don't like it.

[toc] | [prev] | [next] | [standalone]

#67170

On Wednesday, July 24, 2019 at 9:45:37 PM UTC-5, Alf P. Steinbach wrote:
> There's the math constants, finally an official standard library pi! :)
> 
> And there's the format library, <url: 
> http://www.zverovich.net/2019/07/23/std-format-cpp20.html>.
> 
> Designated initializers for structs.
> 
> The spaceship operator (more full fledged support for functionality like 
> `memcmp` and `std::basic_string::compare`).
> 
> Calendar functionality in <chrono>.
> 
> Ranges (but while most everybody's happy with that I think that library 
> gives verbose and impenetrable source code and adds inefficiency, and 
> constitutes yet another large sub-language - I much prefer my own simple 
> `up_to(n)` to the Ranges library's x times renamed unnatural something).
> 
> Coroutines.
> 
> Modules!
> 
> But while I very much want modules I'm not so happy to get them in 
> C++20. I think the modules thing is very much premature. Until they've 
> got Boost expressed as modules there's no relevant real world 
> experience, and the fact that they don't indicates it's not good enough.
> 

I'm not sure these things will help me much.  I mentioned Coroutines
already.  Maybe serialization support for chrono types?


Brian
https://github.com/Ebenezer-group/onwards

[toc] | [prev] | [next] | [standalone]

#67171

On 25/07/2019 16:49, woodbrian77@gmail.com wrote:
> On Wednesday, July 24, 2019 at 9:45:37 PM UTC-5, Alf P. Steinbach wrote:
>> There's the math constants, finally an official standard library pi! :)
>>
>> And there's the format library, <url: 
>> http://www.zverovich.net/2019/07/23/std-format-cpp20.html>.
>>
>> Designated initializers for structs.
>>
>> The spaceship operator (more full fledged support for functionality like 
>> `memcmp` and `std::basic_string::compare`).
>>
>> Calendar functionality in <chrono>.
>>
>> Ranges (but while most everybody's happy with that I think that library 
>> gives verbose and impenetrable source code and adds inefficiency, and 
>> constitutes yet another large sub-language - I much prefer my own simple 
>> `up_to(n)` to the Ranges library's x times renamed unnatural something).
>>
>> Coroutines.
>>
>> Modules!
>>
>> But while I very much want modules I'm not so happy to get them in 
>> C++20. I think the modules thing is very much premature. Until they've 
>> got Boost expressed as modules there's no relevant real world 
>> experience, and the fact that they don't indicates it's not good enough.
>>
> 
> I'm not sure these things will help me much.  I mentioned Coroutines
> already.  Maybe serialization support for chrono types?
> 

We can only guess what might be helpful to /you/ on one single project.
 But that would be a rather specific and personal thread anyway.  I
think it is helpful to hear what others think might be features of
interest to them, or of likely wider interest.

I tried to answer your specific question of "what am I missing?"
regarding coroutines.  Hopefully that was helpful to you.

[toc] | [prev] | [next] | [standalone]

#67364

On 25/07/2019 03:45, Alf P. Steinbach wrote:
> On 25.07.2019 04:10, woodbrian77@gmail.com wrote:
>> B"H
>>
>> So far the only thing I've found in 2020 C++ that seems
>> helpful to me is std::span.  I posted a question about coroutines:
>> https://www.reddit.com/r/cpp_questions/comments/c6mbls/coroutines/
>>
>> and that didn't seem like a fruitful avenue.  What am I
>> missing?  Thanks in advance.
>
> There's the math constants, finally an official standard library pi! :)


woo, no need to define it always ourselves

[toc] | [prev] | [next] | [standalone]

#67161

On 25/07/2019 04:10, woodbrian77@gmail.com wrote:
> B"H
> 
> So far the only thing I've found in 2020 C++ that seems 
> helpful to me is std::span.  I posted a question about coroutines:
> https://www.reddit.com/r/cpp_questions/comments/c6mbls/coroutines/
> 
> and that didn't seem like a fruitful avenue.  What am I
> missing?  Thanks in advance.
> 

I think you are missing an understanding of how coroutines work, and
what they can do for your code structure.

One rough analogy is that coroutines are to threads what cooperative
multitasking is to pre-emptive multitasking.  Clearly, pre-emptive
multitasking and threads have their advantages for many uses - they can
be prioritised automatically, they can run in parallel on different
cores, and they stop bad processes from blocking the system.  But
cooperative has its advantages too.  They are much easier for
synchronisation and access to shared data - /you/ decide where tasks
block and other tasks can take over, eliminating all sorts of locking
and atomicity issues.  They are lightweight, flexible, easy to
understand, and easy (or easier) to debug.

In comparison to asynchronous processes with callbacks, they are easier
to write and clearer to read, while maintaining the lightweight
features.  A clear indication is what you see when you write the code.
With asynchronous processes with callbacks, you often see a code
structure of a function call with a lambda, which contains a function
call with a lambda, and so on - a new level of indentation for every
step.  Your code is one statement - a single function call - that spans
perhaps dozens of lines of highly indented source code.  The equivalent
written using coroutines will look like normal, sequential code, and can
contain whatever mix of statements, declarations, comments, etc., that
you like.

So I am looking forward to coroutines.  I think it will take a while for
support to mature and be efficient in compilers, but it will give us a
new way to structure code.




Other than that, in C++20 I look forward to concepts and modules.  The
spaceship operator will simplify some kinds of classes.  Then there are
lots of small but nice features - more constexpr, consteval, etc.
Ranges are another big feature - I don't know quite how well that will
work out, but it is certainly interesting.

[toc] | [prev] | [next] | [standalone]

#67162

On 25.07.2019 10:05, David Brown wrote:
> [snip]
> Other than that, in C++20 I look forward to concepts and modules.

No concepts yet, sorry.

> The spaceship operator will simplify some kinds of classes.  Then there are
> lots of small but nice features - more constexpr, consteval, etc.
> Ranges are another big feature - I don't know quite how well that will
> work out, but it is certainly interesting.

Uhm, details and over-engineering, IMO. But I think the format library 
will contribute to making C++ programming easier. And calendar stuff and 
specification of what the epoch is, has been sorely missing.

On the strongly negative side, it looks as though the change of return 
type for `std::filesystem::path::u8string` is there for keeps. That 
means correct code for Windows needs to be modified to still compile 
with C++20, and it means in Windows one can't obtain an UTF8-encoded 
std::string from a path without an extra round of copying, inefficiency.

They're not stupid.

 From Reddit discussion with one of them, judging by the very 
intelligent side-steps, generalizations, attempts to mislead etc., I'm 
fairly certain that they do understand what they do, that it's politics 
again.


Cheers!,

- Alf

[toc] | [prev] | [next] | [standalone]

#67165

On 25/07/2019 10:14, Alf P. Steinbach wrote:
> On 25.07.2019 10:05, David Brown wrote:
>> [snip]
>> Other than that, in C++20 I look forward to concepts and modules.
> 
> No concepts yet, sorry.

Did they not make it to C++20 in the end?  Why not?  They are a /really/
nice idea, IMHO.

> 
>> The spaceship operator will simplify some kinds of classes.  Then
>> there are
>> lots of small but nice features - more constexpr, consteval, etc.
>> Ranges are another big feature - I don't know quite how well that will
>> work out, but it is certainly interesting.
> 
> Uhm, details and over-engineering, IMO. 

For my programming, constexpr and now consteval are definitely good.  It
is not uncommon for me to need tables of various sorts, and filling them
at compile time in C++ is a good deal neater than using external code
generators as part of the build process.

Or did you mean that Ranges are over-engineering?  I haven't looked at
them enough to judge.

> But I think the format library
> will contribute to making C++ programming easier. 

Yes, that looks nice.  It combines the advantages of printf with the
advantages of a C++ type-safe solution.

> And calendar stuff and
> specification of what the epoch is, has been sorely missing.

If you say so - I haven't needed that.

> 
> On the strongly negative side, it looks as though the change of return
> type for `std::filesystem::path::u8string` is there for keeps. That
> means correct code for Windows needs to be modified to still compile
> with C++20, and it means in Windows one can't obtain an UTF8-encoded
> std::string from a path without an extra round of copying, inefficiency.
> 

These are not features I have looked at.  But when I see things that
were introduced in C++17 and changed in C++20, it looks bad.

> They're not stupid.
> 
> From Reddit discussion with one of them, judging by the very intelligent
> side-steps, generalizations, attempts to mislead etc., I'm fairly
> certain that they do understand what they do, that it's politics again.
> 

Strings and encodings are always a bit of a mess.  I doubt that there is
any way to get a result that everyone would be happy with, especially
with so much legacy in utf-16 (Windows, NTFS, QT, etc.).

[toc] | [prev] | [next] | [standalone]

#67166

On 2019-07-25 at 10:48, David Brown wrote:
> On 25/07/2019 10:14, Alf P. Steinbach wrote:
>> On 25.07.2019 10:05, David Brown wrote:
>>> [snip]
>>> Other than that, in C++20 I look forward to concepts and modules.
>>
>> No concepts yet, sorry.
> 
> Did they not make it to C++20 in the end?  Why not?  They are a /really/
> nice idea, IMHO.
> 

They did make it, actually. It's contracts that has been delayed.


Kind of confusing that everything seems to start with "co".


    Bo Persson

[toc] | [prev] | [next] | [standalone]

#67167

On 25/07/2019 11:22, Bo Persson wrote:
> On 2019-07-25 at 10:48, David Brown wrote:
>> On 25/07/2019 10:14, Alf P. Steinbach wrote:
>>> On 25.07.2019 10:05, David Brown wrote:
>>>> [snip]
>>>> Other than that, in C++20 I look forward to concepts and modules.
>>>
>>> No concepts yet, sorry.
>>
>> Did they not make it to C++20 in the end?  Why not?  They are a /really/
>> nice idea, IMHO.
>>
> 
> They did make it, actually. It's contracts that has been delayed.
> 

Oh, good.  I had thought they were included, but assumed Alf had read
more up-to-date details on C++20 than I had.

contracts will also be nice, but I don't think they have had much of a
trial period as yet.  (Concepts have been in gcc since version 7.)

> 
> Kind of confusing that everything seems to start with "co".
> 

Actually, what is confusing is that we are running out of "metanames".
Any word for describing groups or features seems to turn into a term in
C++.  "C++20 introduces a range of new concepts...".  I expect that for
C++23 there will be a new feature called "features" :-)

[toc] | [prev] | [next] | [standalone]

#67168

Le jeudi 25 juillet 2019 19:28:23 UTC+9, David Brown a écrit :
> On 25/07/2019 11:22, Bo Persson wrote:
> > On 2019-07-25 at 10:48, David Brown wrote:
> >> On 25/07/2019 10:14, Alf P. Steinbach wrote:
> >>> On 25.07.2019 10:05, David Brown wrote:
> >>>> [snip]
> >>>> Other than that, in C++20 I look forward to concepts and modules.
> >>>
> >>> No concepts yet, sorry.
> >>
> >> Did they not make it to C++20 in the end?  Why not?  They are a /really/
> >> nice idea, IMHO.
> >>
> > 
> > They did make it, actually. It's contracts that has been delayed.
> > 
> 
> Oh, good.  I had thought they were included, but assumed Alf had read
> more up-to-date details on C++20 than I had.
> 
> contracts will also be nice, but I don't think they have had much of a
> trial period as yet.  (Concepts have been in gcc since version 7.)
> 
> > 
> > Kind of confusing that everything seems to start with "co".
> > 
> 
> Actually, what is confusing is that we are running out of "metanames".
> Any word for describing groups or features seems to turn into a term in
> C++.  "C++20 introduces a range of new concepts...".  I expect that for
> C++23 there will be a new feature called "features" :-)

range and concept are the most massive new feature C++ ever got from a standard.
Think about, it the biggest revision so far was C++11.
What paradigm shift did we get from it ?
-> lambdas
thanks to that, we are now halfway to (possibly) functional programming.

With C++20, the loop is closed because we have now as much generic type expressiveness as Haskell does.

Before we had:
templates -> universal types
now we add:
concepts -> existential types
the two quantifiers are now reunited. w00t.
this is huge.

C++ is now joining club with the likes of D, Nim, and Haskell, and even ahead of Swift which plans to get existentials. Even rust is not yet there https://varkor.github.io/blog/2018/07/03/existential-types-in-rust.html.

The consequences of that, is mostly peekable through the rangeV3 library on Eric Niebler's site.
Basically we'll now be able to program like if we had C#'s LINQ, but in C++ and with no overhead.
All the boost iterator adaptors goodness accessible with minimum fuzz, right there natively.

horray to filtered iteration a la jinja:
for (auto stuff : collection | only_interesting_dudes_btw)
{}

the pipe filter will not cost a thing, it will be evaluated as the underlying iterator goes; this should remind you of python's generator. And you'd be right because (I suppose) it's possible thanks to coroutines.

The direct availability of views, filters and adaptors will change how we write code. We'll have super cool pure functional queries instead of ugly loop counters and stateful code with 50 lines and copies or moves into intermediate values and stuff.

like such:
map<int,string> stuff;
function_that_only_takes_string_collections(stuff | second_adaptor); // BOOM

good luck without C++20 for this one.
You'd be forced to copy your strings into a temporary collection.
Or to use a custom written iterator if you're lucky enough that the API designer gave you template iterators for begin/end parameters.
Or integrate boost which most project hate to do because of how heavy it is.

[toc] | [prev] | [next] | [standalone]

#67169

On Thu, 2019-07-25, David Brown wrote:
> On 25/07/2019 11:22, Bo Persson wrote:
>> On 2019-07-25 at 10:48, David Brown wrote:
>>> On 25/07/2019 10:14, Alf P. Steinbach wrote:
>>>> On 25.07.2019 10:05, David Brown wrote:
>>>>> [snip]
>>>>> Other than that, in C++20 I look forward to concepts and modules.
>>>>
>>>> No concepts yet, sorry.
>>>
>>> Did they not make it to C++20 in the end?  Why not?  They are a /really/
>>> nice idea, IMHO.
>>>
>> 
>> They did make it, actually. It's contracts that has been delayed.
>> 
>
> Oh, good.  I had thought they were included, but assumed Alf had read
> more up-to-date details on C++20 than I had.
>
> contracts will also be nice, but I don't think they have had much of a
> trial period as yet.  (Concepts have been in gcc since version 7.)
>
>> 
>> Kind of confusing that everything seems to start with "co".
>> 
>
> Actually, what is confusing is that we are running out of "metanames".
> Any word for describing groups or features seems to turn into a term in
> C++.  "C++20 introduces a range of new concepts...".  I expect that for
> C++23 there will be a new feature called "features" :-)

:-)

Reminds me of Perl, where "thingie" has a well-defined meaning.
Although that's more Larry Wall's sense of humor than running
out of names.

Personally, what I'd like to see in C++ is what Stroustrup asked for
the other year: slower and more reliable progress.  I'm still on C++11.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#67172

On 25/07/2019 16:16, Jorgen Grahn wrote:

> Personally, what I'd like to see in C++ is what Stroustrup asked for
> the other year: slower and more reliable progress.  I'm still on C++11.
> 
> /Jorgen
> 

I think many of the changes can lead to simpler programs, and in
particular, make it simpler to work with better choices of type.  That
in turn means safer code as it is more likely for errors to be caught at
compile time.

In particular, "concepts" give you a grade between "any type" (i.e.,
"auto", or template parameter "T") and fixed, concrete types.  They will
mean you can write functions that deal with a "Number" - it could be any
kind of a number, but it would not be a string or a pointer.  You will
be able to write template classes and functions that work with
particular groups of types, without error-prone, ugly and barely
comprehensible "enable_if" clauses.  And when something goes wrong, the
error messages should be a lot clearer.

[toc] | [prev] | [next] | [standalone]

#67173

On 7/25/2019 12:28 PM, David Brown wrote:
> On 25/07/2019 11:22, Bo Persson wrote:
>> On 2019-07-25 at 10:48, David Brown wrote:
>>> On 25/07/2019 10:14, Alf P. Steinbach wrote:
>>>> On 25.07.2019 10:05, David Brown wrote:
>>>>> [snip]
>>>>> Other than that, in C++20 I look forward to concepts and modules.
>>>>
>>>> No concepts yet, sorry.
>>>
>>> Did they not make it to C++20 in the end?  Why not?  They are a /really/
>>> nice idea, IMHO.
>>>
>>
>> They did make it, actually. It's contracts that has been delayed.
>>
> 
> Oh, good.  I had thought they were included, but assumed Alf had read
> more up-to-date details on C++20 than I had.
> 
> contracts will also be nice, but I don't think they have had much of a
> trial period as yet.  (Concepts have been in gcc since version 7.)
> 
>>
>> Kind of confusing that everything seems to start with "co".
>>
> 
> Actually, what is confusing is that we are running out of "metanames".
> Any word for describing groups or features seems to turn into a term in
> C++.  "C++20 introduces a range of new concepts...".  I expect that for
> C++23 there will be a new feature called "features" :-)
> 
> 
> 

To this point I think that, even if the feature itself is really good, 
the name "concept" is just a bad choice.
They are in fact requirements on template arguments, that Alex Stepanov 
named as concepts with what looks to me a sort of philosophical jump:
apparently he assumes that that a set of requirements on "something" is 
what defines such "something", and it is therefore identical to the 
concept of such "something".

Now, while this may be an excellent argument for discussion, IMHO it is 
just confusing when applied into a programming language (and possibly 
one of the reasons for the tormented gestation of the feature). 
Personally I would have preferred a name more directly coupled to 
"requirement" as in fact they are (we already have typedef, typereq 
might have been something clearer).

But Stroustrup takes Stepanov in very good consideration, so that's the 
name we get.

[toc] | [prev] | [next] | [standalone]

#67335

Manfred writes:

> [C++20 to have "concepts"]
>
> To this point I think that, even if the feature itself is really good,
> the name "concept" is just a bad choice.

Me too.  "Concept" is a terrible choice of name for this
construct.

> They are in fact requirements on template arguments, that Alex
> Stepanov named as concepts with what looks to me a sort of
> philosophical jump:
> apparently he assumes that that a set of requirements on "something"
> is what defines such "something", and it is therefore identical to the
> concept of such "something".
>
> Now, while this may be an excellent argument for discussion, IMHO it
> is just confusing when applied into a programming language (and
> possibly one of the reasons for the tormented gestation of the
> feature).  Personally I would have preferred a name more directly
> coupled to "requirement" as in fact they are (we already have typedef,
> typereq might have been something clearer).

The name "constraint" isn't quite right because a C++ "concept"
doesn't yet constrain anything;  it is more like what might be
called a "constraint-in-waiting".

The name "requirement" isn't quite right for much the same kinds
of reasons:  by itself a C++ "concept" doesn't require anything.
We might call it a "statement of requirements", if that phrase
weren't so cumbersome.  Also there are parts of C++ "concepts"
that use the keyword 'requires' and might themselves be called
"requirements", which is confusing.

A name I am starting to warm up to is "property".  It fits with
lots of the examples on the cppreference page:  the "Hashable"
property, the "Incrementable" property, the "Addable" property,
etc.  When attaching a 'requires' constraint to a type T, we can
say "T must have the Hashable property", which to my ears sounds
better than "T must satisfy the Hashable requirements".

Just my thoughts, for what that might be worth.

[toc] | [prev] | [next] | [standalone]

#67336

On Tue, 06 Aug 2019 09:31:00 -0700, Tim Rentsch
<tr.17687@z991.linuxsc.com> wrote:

>A name I am starting to warm up to is "property".  It fits with
>lots of the examples on the cppreference page:  the "Hashable"
>property, the "Incrementable" property, the "Addable" property,
>etc.

Those words sound like "capabilities" to me, which seems appropriate
to the suffix "...able" on those names.
--
Fran

[toc] | [prev] | [next] | [standalone]

#67500

Fran <flitterio@gmail.com> writes:

> On Tue, 06 Aug 2019 09:31:00 -0700, Tim Rentsch
> <tr.17687@z991.linuxsc.com> wrote:
>
>> A name I am starting to warm up to is "property".  It fits with
>> lots of the examples on the cppreference page:  the "Hashable"
>> property, the "Incrementable" property, the "Addable" property,
>> etc.
>
> Those words sound like "capabilities" to me, which seems appropriate
> to the suffix "...able" on those names.

Despite how the words might sound, "capability" is not a good fit for
a C++ concept, which supplies nothing in the way of implementation.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web