------=_Part_40_541882689.1464631763570
Content-Type: multipart/alternative;
 boundary="----=_Part_41_1462138049.1464631763570"

------=_Part_41_1462138049.1464631763570
Content-Type: text/plain; charset=UTF-8

A while back, we had a paper-based discussion about putting the Concepts TS
into C++17.

On the one hand, P0225 laid out an argument for why concepts is exceedingly
important and mature as-is, therefore it is reasonable to adopt it.

On the other hand, P0240 laid out an argument that it was missing elements
(notably definition checking), and that lacking these elements would
effectively make getting them impossible due to breaking compatibility. It
also argued that the design of the Concepts TS could use some refactoring.

Things went back and forth for a while. But one argument struck me as
utterly bizarre, which lead me to a question:

> Why would you ever want to have a conceptualized template where the
definition *wasn't* checked?

I kept thinking about that question for a long time, as it seemed
completely baffling to me. After all, you put the concept in the template,
so you clearly wanted to conform to it. But then, all at once I understood.
And if you read through P0225, it's all right there too. It all boils down
to this unstated fact:

There is a semantic difference between *Constraints* and *Concepts*.

*Constraints* are merely a language-based form of `enable_if`. And if you
look at P0225, *all* of the arguments made there in favor of Concepts TS
talk about its use only as a replacement for `enable_if`. Concepts doesn't
disturb the airily of functions. It doesn't affect argument deduction. It
allows easy writing of overloads of different things. And so forth.

All of those are uses of applying concepts to templates, not as actual
full-fledged *concepts*, but merely as SFINAE `enable_if` gymnastics, only
with good syntax.

*Concepts* are about something more than merely being `enable_if` without
the crappy syntax. Constraints simply say when a function/type may or may
not exist. Concepts make a much stronger statement about the *meaning* of a
piece of code. A concept is a constraint, but it constrains both halves of
the code.

A function which constrains a parameter against a particular set of rules
says that the function won't exist if you don't pass a type that follows
those rules. A function which applies a *concept* to a parameter makes a
stronger statement about the behavior of that function. When
`vector<T>::emplace_back` is constrained for argument sequences from which
`T` is constructible, that is a constraint. But it is *also* a promise that
`emplace_back` will not attempt to do anything more with `T` than that (and
copying/moving, should reallocation occur).

You can see this dichotomy in how the Concepts TS we have now came to be.
It wasn't an outgrowth of a full concepts system; it was more of an
outgrowth of *static_if*, a pure-constraint mechanism. Concepts-lite was a
proposal that was made in response to a D-style static_if proposal
(ironically, `constexpr if` is now more likely to see C++17 than Concepts
TS). As such, it's primary focus is constraints, with full concepts as an
optional extra.

However, what we realize is that we don't need constraints or concepts. We
need *both*.

Both concepts and constraints are based on a named series of expressions,
of rules against which a type or types are checked against. So we don't
want to have two systems that are so similar to one another but are
specified in different ways. At the same time, we need to be able to
differentiate between constraint `enable_if` uses and full-blown concepts.

I think the Concepts TS can provide both constraints and concepts. I can
see two ways of doing it:

1) Make the distinction where the concept is defined. That is, have
`constraint bool ...` and `concept bool ...`.

2) Make the distinction where the concept is *used*. `template<concept Name
T>`, for example will apply the rules specified by `Name` as a concept.
`template<constraint Name T>` would apply it as a constraint, which would
perhaps be the default case.

We could even allow both. That is, if you just use `template<Name T>`, then
if `Name` is a constraint, then it is used as a constraint. However, you
could do `template<concept Name T>` which would override the definition and
force it to be applied as a concept. And vice versa (though I'm not as sure
about that).

And what would it mean to apply a set of rules as a concept? For the
moment, simply this:

> If a set of rules is applied as a concept, then any use of the
objects/etc in the template which is not specified by one of the rules is
undefined behavior. Or maybe il-formed, but no diagnostic required.

This way, unchecked definitions are permitted to successfully compile and
even successfully *execute*. But users who specify a concept agree up-front
that they are not *violating* it.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f0b8f7da-28f0-43fb-9073-ceb2aa32a032%40isocpp.org.

------=_Part_41_1462138049.1464631763570
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A while back, we had a paper-based discussion about puttin=
g the Concepts TS into C++17.<br><br>On the one hand, P0225 laid out an arg=
ument for why concepts is exceedingly important and mature as-is, therefore=
 it is reasonable to adopt it.<br><br>On the other hand, P0240 laid out an =
argument that it was missing elements (notably definition checking), and th=
at lacking these elements would effectively make getting them impossible du=
e to breaking compatibility. It also argued that the design of the Concepts=
 TS could use some refactoring.<br><br>Things went back and forth for a whi=
le. But one argument struck me as utterly bizarre, which lead me to a quest=
ion:<br><br>&gt; Why would you ever want to have a conceptualized template =
where the definition <i>wasn&#39;t</i> checked?<br><br>I kept thinking abou=
t that question for a long time, as it seemed completely baffling to me. Af=
ter all, you put the concept in the template, so you clearly wanted to conf=
orm to it. But then, all at once I understood. And if you read through P022=
5, it&#39;s all right there too. It all boils down to this unstated fact:<b=
r><br>There is a semantic difference between <b>Constraints</b> and <b>Conc=
epts</b>.<br><br><b>Constraints</b> are merely a language-based form of `en=
able_if`. And if you look at P0225, <i>all</i> of the arguments made there =
in favor of Concepts TS talk about its use only as a replacement for `enabl=
e_if`. Concepts doesn&#39;t disturb the airily of functions. It doesn&#39;t=
 affect argument deduction. It allows easy writing of overloads of differen=
t things. And so forth.<br><br>All of those are uses of applying concepts t=
o templates, not as actual full-fledged <i>concepts</i>, but merely as SFIN=
AE `enable_if` gymnastics, only with good syntax.<br><br><b>Concepts</b> ar=
e about something more than merely being `enable_if` without the crappy syn=
tax. Constraints simply say when a function/type may or may not exist. Conc=
epts make a much stronger statement about the <i>meaning</i> of a piece of =
code. A concept is a constraint, but it constrains both halves of the code.=
<br><br>A function which constrains a parameter against a particular set of=
 rules says that the function won&#39;t exist if you don&#39;t pass a type =
that follows those rules. A function which applies a <i>concept</i> to a pa=
rameter makes a stronger statement about the behavior of that function. Whe=
n `vector&lt;T&gt;::emplace_back` is constrained for argument sequences fro=
m which `T` is constructible, that is a constraint. But it is <i>also</i> a=
 promise that `emplace_back` will not attempt to do anything more with `T` =
than that (and copying/moving, should reallocation occur).<br><br>You can s=
ee this dichotomy in how the Concepts TS we have now came to be. It wasn&#3=
9;t an outgrowth of a full concepts system; it was more of an outgrowth of =
<i>static_if</i>, a pure-constraint mechanism. Concepts-lite was a proposal=
 that was made in response to a D-style static_if proposal (ironically, `co=
nstexpr if` is now more likely to see C++17 than Concepts TS). As such, it&=
#39;s primary focus is constraints, with full concepts as an optional extra=
..<br><br>However, what we realize is that we don&#39;t need constraints or =
concepts. We need <i>both</i>.<br><br>Both concepts and constraints are bas=
ed on a named series of expressions, of rules against which a type or types=
 are checked against. So we don&#39;t want to have two systems that are so =
similar to one another but are specified in different ways. At the same tim=
e, we need to be able to differentiate between constraint `enable_if` uses =
and full-blown concepts.<br><br>I think the Concepts TS can provide both co=
nstraints and concepts. I can see two ways of doing it:<br><br>1) Make the =
distinction where the concept is defined. That is, have `constraint bool ..=
..` and `concept bool ...`.<br><br>2) Make the distinction where the concept=
 is <i>used</i>. `template&lt;concept Name T&gt;`, for example will apply t=
he rules specified by `Name` as a concept. `template&lt;constraint Name T&g=
t;` would apply it as a constraint, which would perhaps be the default case=
..<br><br>We could even allow both. That is, if you just use `template&lt;Na=
me T&gt;`, then if `Name` is a constraint, then it is used as a constraint.=
 However, you could do `template&lt;concept Name T&gt;` which would overrid=
e the definition and force it to be applied as a concept. And vice versa (t=
hough I&#39;m not as sure about that).<br><br>And what would it mean to app=
ly a set of rules as a concept? For the moment, simply this:<br><br>&gt; If=
 a set of rules is applied as a concept, then any use of the objects/etc in=
 the template which is not specified by one of the rules is undefined behav=
ior. Or maybe il-formed, but no diagnostic required.<br><br>This way, unche=
cked definitions are permitted to successfully compile and even successfull=
y <i>execute</i>. But users who specify a concept agree up-front that they =
are not <i>violating</i> it.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f0b8f7da-28f0-43fb-9073-ceb2aa32a032%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f0b8f7da-28f0-43fb-9073-ceb2aa32a032=
%40isocpp.org</a>.<br />

------=_Part_41_1462138049.1464631763570--

------=_Part_40_541882689.1464631763570--

.

On 30 May 2016 at 21:09, Nicol Bolas <jmckesson@gmail.com> wrote:
> of static_if, a pure-constraint mechanism. Concepts-lite was a proposal that
> was made in response to a D-style static_if proposal (ironically, `constexpr

Well, that's utter nonsense, so before you have educated yourself
about the history
of Concepts, I don't think I should discuss Concepts design with you.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZEj65G_946JtNA6QyfpKziR25PRsC-7PdKVrpLrtP44A%40mail.gmail.com.

.

On 30 May 2016 at 21:09, Nicol Bolas <jmckesson@gmail.com> wrote:
> A while back, we had a paper-based discussion about putting the Concepts TS
> into C++17.
>
> On the one hand, P0225 laid out an argument for why concepts is exceedingly
> important and mature as-is, therefore it is reasonable to adopt it.
>
> On the other hand, P0240 laid out an argument that it was missing elements
> (notably definition checking), and that lacking these elements would
> effectively make getting them impossible due to breaking compatibility. It
> also argued that the design of the Concepts TS could use some refactoring.
>
> Things went back and forth for a while. But one argument struck me as
> utterly bizarre, which lead me to a question:
>
>> Why would you ever want to have a conceptualized template where the
>> definition wasn't checked?

If you need to use a legacy template in the implementation of a
constrained template, and you don't
want to constrain the legacy template (possibly because it needs to
work with pre-c++20 code, possibly
because it does something that shouldn't appear in the interface of
your constrained template, and it
still always works within your constraints). The concepts papers
mention tracing and telemetry. In addition
to those, there are cases where said legacy templates match the
constraints of your constrained templates
but need not or cannot advertise that as constraints. Forced
definition checking doesn't let you do any of
those things, which has been proven to cause difficulties with
migration paths from unconstrained to constrained
templates, and to cause scaling problems because all operations the
template performs must be defined in
the constraints. Even operations like dumping memory addresses or
object representations to debugging
facilities, and especially doing so conditionally. The designers of
Concepts considered such aspects, and
deemed definition checking to be not quite ready to handle such uses
properly, and thought that a more
focused facility would cover many or even most important use cases,
and be a massive improvement
while further facilities are explored. And they were 100% right.


> I kept thinking about that question for a long time, as it seemed completely
> baffling to me. After all, you put the concept in the template, so you
> clearly wanted to conform to it. But then, all at once I understood. And if
> you read through P0225, it's all right there too. It all boils down to this
> unstated fact:
>
> There is a semantic difference between Constraints and Concepts.
>
> Constraints are merely a language-based form of `enable_if`. And if you look

That's an incorrect simplification. Concepts as proposed, and the
constraint language they use,
provide a means to write generic interfaces. enable_if can be abused
to do something remotely like that in a very
indirect manner, making the main use cases of constrained interfaces
very tedious to express and
reason about (both for compilers and humans). Concepts are not a
"language-based form of enable_if", they
solve a very focused problem in a manner highly superior to what
enable_if can bring to the table.

> at P0225, all of the arguments made there in favor of Concepts TS talk about
> its use only as a replacement for `enable_if`. Concepts doesn't disturb the

They talk about using Concepts to solve problems that are annoyingly
difficult to solve with enable_if. The only
aspect where Concepts are a replacement to enable_if is enable_if
being currently the only solution to any
such problems.

> airily of functions. It doesn't affect argument deduction. It allows easy
> writing of overloads of different things. And so forth.

The ability to write constrained interfaces for generic code without
disturbing deduction is of fundamental
importance. With enable_if, I need to resort to all sorts of brittle
nonsense to get to that destination.
With Concepts, I can write such interfaces directly, without separate
traits-wrapped logical combinations in
the declaration. I can emulate that goal to some extent; I recommend
looking at libstdc++'s <tuple> and the
tuple constructors for some examples. I have almost-predicates which
are constexpr functions. I still need
to wrap them inside an enable_if to constrain interfaces. With
Concepts, such wrapping becomes completely
unnecessary. I get constrained interfaces without the 'gymnastics'
mentioned below, and that's not such
syntactic sugar. I also get a well-defined and well-ordered constraint
evaluation model that makes it far easier to write constraints
and their combinations. And I get all that for both templates and non-templates.

>
> All of those are uses of applying concepts to templates, not as actual
> full-fledged concepts, but merely as SFINAE `enable_if` gymnastics, only
> with good syntax.

The 'gymnastics' vanish almost completely when Concepts are available.
Mostly because the 'gymnastics'
are what I currently *have* to write, whereas with Concepts, I don't
need to resort to such 'gymnastics' at all.


> Concepts are about something more than merely being `enable_if` without the
> crappy syntax. Constraints simply say when a function/type may or may not
> exist. Concepts make a much stronger statement about the meaning of a piece
> of code. A concept is a constraint, but it constrains both halves of the
> code.

Well, now you're talking about "Concepts" which may or may not
materialize. The definition-checking half
certainly hasn't materialized yet in any form that would be viable.
And I have sufficient practical experience
and evidence that I know that "Concepts" that constrain "both halves"
of code so that they always constrain
both the interface and the definition, without letting me constrain
just the interface, are not worth the trouble.
They are a useless non-starter for practical purposes where
programmers need to deal with existing codebases, compatibility
and migration paths.

> A function which constrains a parameter against a particular set of rules
> says that the function won't exist if you don't pass a type that follows
> those rules. A function which applies a concept to a parameter makes a
> stronger statement about the behavior of that function. When
> `vector<T>::emplace_back` is constrained for argument sequences from which
> `T` is constructible, that is a constraint. But it is also a promise that
> `emplace_back` will not attempt to do anything more with `T` than that (and
> copying/moving, should reallocation occur).

That is, I suppose, one way to look at "interface concepts" vs.
"definition concepts", but I don't find that
terminology of "constraints" meaning the former and "concepts" meaning
the latter or both to be palatable.
Concepts are a high-level mechanism for applying constraints, not some
light/matter twin of a new meaning
of the word 'constraint'.

> You can see this dichotomy in how the Concepts TS we have now came to be. It
> wasn't an outgrowth of a full concepts system; it was more of an outgrowth

Sure, it wasn't an "outgrowth", it was a subset of a larger idea,
providing a subset that can
be specified and implemented. Both of which have been done.

> of static_if, a pure-constraint mechanism. Concepts-lite was a proposal that
> was made in response to a D-style static_if proposal (ironically, `constexpr
> if` is now more likely to see C++17 than Concepts TS). As such, it's primary
> focus is constraints, with full concepts as an optional extra.

Revisionist history at its best. The work on Concepts Lite happened
separately and before
there ever was a proposal for a D-style static if for C++.

> However, what we realize is that we don't need constraints or concepts. We
> need both.

If you mean that we need both interface constraints and definition
constraints, maybe.
Maybe not. I don't need the latter. I do need the former. I need them
separately from the latter.

> Both concepts and constraints are based on a named series of expressions, of
> rules against which a type or types are checked against. So we don't want to
> have two systems that are so similar to one another but are specified in
> different ways. At the same time, we need to be able to differentiate
> between constraint `enable_if` uses and full-blown concepts.

I don't think anyone has claimed that interface vs. definition
constraints need to be specified
different ways. I would, however, expect that applying such
constraints to templates will need to
look different, somewhere, somehow. I cannot accept my
interface-constrained templates
being suddenly automatically definition-checked. I don't think I'd
have any trouble with the
opposite, having definition-checked templates automatically be
interface-checked.

I don't know what syntax should be used for definition checking.
Mostly because I am not at a point
where that is important to me. The use cases where I imagine I need
definition checking are vanishingly rare, and
even those are not completely immune to the problems that definition
checking has with existing-duck-typed-templates,
tracing and telemetry. None of those problems arise for interface
checking, and the alleged benefits of definition
checking are attainable via other less intrusive means.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaiY9uZOrVxxC8h0ZDoMnJjG-LX9kn9WDcZkdSv8ha5pQ%40mail.gmail.com.

.

------=_Part_913_196428075.1464651047759
Content-Type: multipart/alternative;
 boundary="----=_Part_914_933475392.1464651047760"

------=_Part_914_933475392.1464651047760
Content-Type: text/plain; charset=UTF-8

On Monday, May 30, 2016 at 4:08:50 PM UTC-4, Ville Voutilainen wrote:
>
> On 30 May 2016 at 21:09, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > A while back, we had a paper-based discussion about putting the Concepts
> TS
> > into C++17.
> >
> > On the one hand, P0225 laid out an argument for why concepts is
> exceedingly
> > important and mature as-is, therefore it is reasonable to adopt it.
> >
> > On the other hand, P0240 laid out an argument that it was missing
> elements
> > (notably definition checking), and that lacking these elements would
> > effectively make getting them impossible due to breaking compatibility.
> It
> > also argued that the design of the Concepts TS could use some
> refactoring.
> >
> > Things went back and forth for a while. But one argument struck me as
> > utterly bizarre, which lead me to a question:
> >
> >> Why would you ever want to have a conceptualized template where the
> >> definition wasn't checked?
>
> If you need to use a legacy template in the implementation of a
> constrained template, and you don't
> want to constrain the legacy template (possibly because it needs to
> work with pre-c++20 code, possibly
> because it does something that shouldn't appear in the interface of
> your constrained template, and it
> still always works within your constraints).


This right here is part of the disconnect we have, and it's part of the
reason why I wanted to invent specific terms to discuss these separate and
distinct ideas. However, I don't really care what they're called, so long
as the *distinction* is clear. So I'll try to use your language for them.

The interface for `range::sort` is well specified. The range it is provided
must conform to a specific set of requirements, and the function it is
given (if any) must also conform to a specific set of requirements. That
creates a contract between the callee and the caller.

In order for a contract to work, this contract must be binding *on both
sides*. The callee must provide at least the required interfaces, much like
the person who derived from a base class must implement the pure-virtual
members. However, the caller must also not attempt to perform any
operations other than those for which the contract is valid. Much like the
user of a base class cannot call functions which were not declared as part
of the interface.

There is absolutely no reason for an implementation of `range::sort` to
violate its contract, to use its parameters in a way that violates the
rules that govern its functionality. Indeed, those rules were created under
the expectation that implementations will not need to do so.

An "interface constraint" is not a *contract*. It is merely a declaration
of requirements on the user's part. A "definition constraint" is a real,
live, compiler-verified *contract* between the caller and the callee.

What I'm saying are the following:

1) We need to have both "interface constraints" and "definition
constraints".

2) We should declare them using similar syntax.

3) We need to be able to use both in similar ways, likely with
interoperation between them.

4) We need "definition constraints" to be part of the concepts syntax *from
day one*, even if we don't actually require compilers to check the
definitions. That way, people (including the Range TS) can write its
concepts as definition constraints, with the expectation that, once
compiler checking comes online, they will handle it.


> > I kept thinking about that question for a long time, as it seemed
> completely
> > baffling to me. After all, you put the concept in the template, so you
> > clearly wanted to conform to it. But then, all at once I understood. And
> if
> > you read through P0225, it's all right there too. It all boils down to
> this
> > unstated fact:
> >
> > There is a semantic difference between Constraints and Concepts.
> >
> > Constraints are merely a language-based form of `enable_if`. And if you
> look
>
> That's an incorrect simplification. Concepts as proposed, and the
> constraint language they use,
> provide a means to write generic interfaces.


*Templates* provide a means to write generic interfaces.

Concepts TS simply provides a means to write *explicitly constrained*
generic interfaces. Interfaces who's usage is verified by the compiler, and
definitions for which can be SFINAE'd away based on their use. These are
things we would have used `enable_if` and similar tools to handle before.
Now we want to use Concepts TS for them.

Boost Lambda was a library way to introduce lambda expressions. We got a
replacement in the form of a language feature to do that. How is this
different, exactly?

enable_if can be abused
> to do something remotely like that in a very
> indirect manner,


I'm curious: what other use for `enable_if` is there than constraining
template instantiations?

> at P0225, all of the arguments made there in favor of Concepts TS talk
> about
> > its use only as a replacement for `enable_if`. Concepts doesn't disturb
> the
>
> They talk about using Concepts to solve problems that are annoyingly
> difficult to solve with enable_if. The only
> aspect where Concepts are a replacement to enable_if is enable_if
> being currently the only solution to any
> such problems.
>

And... it currently is. In C++14, if you want to constrain a template, you
must do so with `enable_if` or some similar tool. So, I'm not sure what
you're trying to say here.


> > airily of functions. It doesn't affect argument deduction. It allows
> easy
> > writing of overloads of different things. And so forth.
>
> The ability to write constrained interfaces for generic code without
> disturbing deduction is of fundamental
> importance. With enable_if, I need to resort to all sorts of brittle
> nonsense to get to that destination.
> With Concepts, I can write such interfaces directly, without separate
> traits-wrapped logical combinations in
> the declaration. I can emulate that goal to some extent; I recommend
> looking at libstdc++'s <tuple> and the
> tuple constructors for some examples. I have almost-predicates which
> are constexpr functions. I still need
> to wrap them inside an enable_if to constrain interfaces. With
> Concepts, such wrapping becomes completely
> unnecessary. I get constrained interfaces without the 'gymnastics'
> mentioned below, and that's not such
> syntactic sugar. I also get a well-defined and well-ordered constraint
> evaluation model that makes it far easier to write constraints
> and their combinations. And I get all that for both templates and
> non-templates.
>

At no point was I arguing against the the *merits* of "interface
constraints"; I was simply restating and summarizing your position within
the larger body of thought on concepts. Specifically, that your points all
matter only to the interface, not to the definition.

> Concepts are about something more than merely being `enable_if` without
> the
> > crappy syntax. Constraints simply say when a function/type may or may
> not
> > exist. Concepts make a much stronger statement about the meaning of a
> piece
> > of code. A concept is a constraint, but it constrains both halves of the
> > code.
>
> Well, now you're talking about "Concepts" which may or may not
> materialize.


Sorry, but I don't read scare-quotes. Can you explain the difference
between "Concepts" and scare-quotes "Concepts"?


> The definition-checking half
> certainly hasn't materialized yet in any form that would be viable.
> And I have sufficient practical experience
> and evidence that I know that "Concepts" that constrain "both halves"
> of code so that they always constrain
> both the interface and the definition, without letting me constrain
> just the interface, are not worth the trouble.
> They are a useless non-starter for practical purposes where
> programmers need to deal with existing codebases, compatibility
> and migration paths.
>

I get that interface contracts aren't something you like to use. Please
explain why that means nobody should be allowed to use contracts either.

> of static_if, a pure-constraint mechanism. Concepts-lite was a proposal
> that
> > was made in response to a D-style static_if proposal (ironically,
> `constexpr
> > if` is now more likely to see C++17 than Concepts TS). As such, it's
> primary
> > focus is constraints, with full concepts as an optional extra.
>
> Revisionist history at its best. The work on Concepts Lite happened
> separately and before
> there ever was a proposal for a D-style static if for C++.
>

But the only publicly available paper trail
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/> dates the first
concepts-lite paper (N3580) 03/17/2013, while the first static_if papers
(N3322 and N3329) at 12/11/2011 and 01/10/2012, both over a year before.
Indeed, N3580 was also released in the same mailing at N3618, which was a
comparison between static_if and concepts-lite. So clearly, the authors of
concepts-lite were aware of the static_if proposals and considered them
competition.

Maybe there were things happening behind closed doors. But from the
information I have available, this is a reasonable description of the
sequence of events.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/097eaff2-2250-4c12-a764-1647de0d9a99%40isocpp.org.

------=_Part_914_933475392.1464651047760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, May 30, 2016 at 4:08:50 PM UTC-4, Ville Voutila=
inen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 30 May 2016 at 2=
1:09, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"y9e9yMIoAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; A while back, we had a paper-based discussion about putting the Co=
ncepts TS
<br>&gt; into C++17.
<br>&gt;
<br>&gt; On the one hand, P0225 laid out an argument for why concepts is ex=
ceedingly
<br>&gt; important and mature as-is, therefore it is reasonable to adopt it=
..
<br>&gt;
<br>&gt; On the other hand, P0240 laid out an argument that it was missing =
elements
<br>&gt; (notably definition checking), and that lacking these elements wou=
ld
<br>&gt; effectively make getting them impossible due to breaking compatibi=
lity. It
<br>&gt; also argued that the design of the Concepts TS could use some refa=
ctoring.
<br>&gt;
<br>&gt; Things went back and forth for a while. But one argument struck me=
 as
<br>&gt; utterly bizarre, which lead me to a question:
<br>&gt;
<br>&gt;&gt; Why would you ever want to have a conceptualized template wher=
e the
<br>&gt;&gt; definition wasn&#39;t checked?
<br>
<br>If you need to use a legacy template in the implementation of a
<br>constrained template, and you don&#39;t
<br>want to constrain the legacy template (possibly because it needs to
<br>work with pre-c++20 code, possibly
<br>because it does something that shouldn&#39;t appear in the interface of
<br>your constrained template, and it
<br>still always works within your constraints).</blockquote><div><br>This =
right here is part of the disconnect we have, and it&#39;s part of the reas=
on why I wanted to invent specific terms to discuss these separate and dist=
inct ideas. However, I don&#39;t really care what they&#39;re called, so lo=
ng as the <i>distinction</i> is clear. So I&#39;ll try to use your language=
 for them.<br><br>The interface for `range::sort` is well specified. The ra=
nge it is provided must conform to a specific set of requirements, and the =
function it is given (if any) must also conform to a specific set of requir=
ements. That creates a contract between the callee and the caller.<br><br>I=
n order for a contract to work, this contract must be binding <i>on both si=
des</i>. The callee must provide at least the required interfaces, much lik=
e the person who derived from a base class must implement the pure-virtual =
members. However, the caller must also not attempt to perform any operation=
s other than those for which the contract is valid. Much like the user of a=
 base class cannot call functions which were not declared as part of the in=
terface.<br><br>There is absolutely no reason for an implementation of `ran=
ge::sort` to violate its contract, to use its parameters in a way that viol=
ates the rules that govern its functionality. Indeed, those rules were crea=
ted under the expectation that implementations will not need to do so.<br><=
br>An &quot;interface constraint&quot; is not a <i>contract</i>. It is mere=
ly a declaration of requirements on the user&#39;s part. A &quot;definition=
 constraint&quot; is a real, live, compiler-verified <i>contract</i> betwee=
n the caller and the callee.<br><br>What I&#39;m saying are the following:<=
br><br>1) We need to have both &quot;interface constraints&quot; and &quot;=
definition constraints&quot;.<br><br>2) We should declare them using simila=
r syntax.<br><br>3) We need to be able to use both in similar ways, likely =
with interoperation between them.<br><br>4) We need &quot;definition constr=
aints&quot; to be part of the concepts syntax <i>from day one</i>, even if =
we don&#39;t actually require compilers to check the definitions. That way,=
 people (including the Range TS) can write its concepts as definition const=
raints, with the expectation that, once compiler checking comes online, the=
y will handle it.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"> &gt; I kept thinking about that question for a long time, as it seemed =
completely
<br>&gt; baffling to me. After all, you put the concept in the template, so=
 you
<br>&gt; clearly wanted to conform to it. But then, all at once I understoo=
d. And if
<br>&gt; you read through P0225, it&#39;s all right there too. It all boils=
 down to this
<br>&gt; unstated fact:
<br>&gt;
<br>&gt; There is a semantic difference between Constraints and Concepts.
<br>&gt;
<br>&gt; Constraints are merely a language-based form of `enable_if`. And i=
f you look
<br>
<br>That&#39;s an incorrect simplification. Concepts as proposed, and the
<br>constraint language they use,
<br>provide a means to write generic interfaces.</blockquote><div><br><i>Te=
mplates</i> provide a means to write generic interfaces.<br><br>Concepts TS=
 simply provides a means to write <i>explicitly constrained</i> generic int=
erfaces. Interfaces who&#39;s usage is verified by the compiler, and defini=
tions for which can be SFINAE&#39;d away based on their use. These are thin=
gs we would have used `enable_if` and similar tools to handle before. Now w=
e want to use Concepts TS for them.<br><br>Boost Lambda was a library way t=
o introduce lambda expressions. We got a replacement in the form of a langu=
age feature to do that. How is this different, exactly?<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"> enable_if can be abused
<br>to do something remotely like that in a very
<br>indirect manner,</blockquote><div><br>I&#39;m curious: what other use f=
or `enable_if` is there than constraining template instantiations?<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; at P0225, all of the=
 arguments made there in favor of Concepts TS talk about
<br>&gt; its use only as a replacement for `enable_if`. Concepts doesn&#39;=
t disturb the
<br>
<br>They talk about using Concepts to solve problems that are annoyingly
<br>difficult to solve with enable_if. The only
<br>aspect where Concepts are a replacement to enable_if is enable_if
<br>being currently the only solution to any
<br>such problems.<br></blockquote><div><br>And... it currently is. In C++1=
4, if you want to constrain a template, you must do so with `enable_if` or =
some similar tool. So, I&#39;m not sure what you&#39;re trying to say here.=
<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; airily of functions. It doesn&#39;t affect argument deduction. It allo=
ws easy
<br>&gt; writing of overloads of different things. And so forth.
<br>
<br>The ability to write constrained interfaces for generic code without
<br>disturbing deduction is of fundamental
<br>importance. With enable_if, I need to resort to all sorts of brittle
<br>nonsense to get to that destination.
<br>With Concepts, I can write such interfaces directly, without separate
<br>traits-wrapped logical combinations in
<br>the declaration. I can emulate that goal to some extent; I recommend
<br>looking at libstdc++&#39;s &lt;tuple&gt; and the
<br>tuple constructors for some examples. I have almost-predicates which
<br>are constexpr functions. I still need
<br>to wrap them inside an enable_if to constrain interfaces. With
<br>Concepts, such wrapping becomes completely
<br>unnecessary. I get constrained interfaces without the &#39;gymnastics&#=
39;
<br>mentioned below, and that&#39;s not such
<br>syntactic sugar. I also get a well-defined and well-ordered constraint
<br>evaluation model that makes it far easier to write constraints
<br>and their combinations. And I get all that for both templates and non-t=
emplates.<br></blockquote><div><br>At no point was I arguing against the th=
e <i>merits</i> of &quot;interface constraints&quot;; I was simply restatin=
g and summarizing your position within the larger body of thought on concep=
ts. Specifically, that your points all matter only to the interface, not to=
 the definition.<br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; Concepts are about something more than merely being `enable_if` withou=
t the
<br>&gt; crappy syntax. Constraints simply say when a function/type may or =
may not
<br>&gt; exist. Concepts make a much stronger statement about the meaning o=
f a piece
<br>&gt; of code. A concept is a constraint, but it constrains both halves =
of the
<br>&gt; code.
<br>
<br>Well, now you&#39;re talking about &quot;Concepts&quot; which may or ma=
y not
<br>materialize.</blockquote><div><br>Sorry, but I don&#39;t read scare-quo=
tes. Can you explain the difference between &quot;Concepts&quot; and scare-=
quotes &quot;Concepts&quot;?<br>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">The definition-checking half
<br>certainly hasn&#39;t materialized yet in any form that would be viable.
<br>And I have sufficient practical experience
<br>and evidence that I know that &quot;Concepts&quot; that constrain &quot=
;both halves&quot;
<br>of code so that they always constrain
<br>both the interface and the definition, without letting me constrain
<br>just the interface, are not worth the trouble.
<br>They are a useless non-starter for practical purposes where
<br>programmers need to deal with existing codebases, compatibility
<br>and migration paths.<br></blockquote><div><br>I get that interface cont=
racts aren&#39;t something you like to use. Please explain why that means n=
obody should be allowed to use contracts either.<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">
&gt; of static_if, a pure-constraint mechanism. Concepts-lite was a proposa=
l that
<br>&gt; was made in response to a D-style static_if proposal (ironically, =
`constexpr
<br>&gt; if` is now more likely to see C++17 than Concepts TS). As such, it=
&#39;s primary
<br>&gt; focus is constraints, with full concepts as an optional extra.
<br>
<br>Revisionist history at its best. The work on Concepts Lite happened
<br>separately and before
<br>there ever was a proposal for a D-style static if for C++.<br></blockqu=
ote><div><br>But the only <a href=3D"http://www.open-std.org/JTC1/SC22/WG21=
/docs/papers/">publicly available paper trail</a> dates the first concepts-=
lite paper (N3580) 03/17/2013, while the first static_if papers (N3322 and =
N3329) at 12/11/2011 and 01/10/2012, both over a year before. Indeed, N3580=
 was also released in the same mailing at N3618, which was a comparison bet=
ween static_if and concepts-lite. So clearly, the authors of concepts-lite =
were aware of the static_if proposals and considered them competition.<br><=
br>Maybe there were things happening behind closed doors. But from the info=
rmation I have available, this is a reasonable description of the sequence =
of events.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/097eaff2-2250-4c12-a764-1647de0d9a99%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/097eaff2-2250-4c12-a764-1647de0d9a99=
%40isocpp.org</a>.<br />

------=_Part_914_933475392.1464651047760--

------=_Part_913_196428075.1464651047759--

.

On 31 May 2016 at 02:30, Nicol Bolas <jmckesson@gmail.com> wrote:
>> If you need to use a legacy template in the implementation of a
>> constrained template, and you don't
>> want to constrain the legacy template (possibly because it needs to
>> work with pre-c++20 code, possibly
>> because it does something that shouldn't appear in the interface of
>> your constrained template, and it
>> still always works within your constraints).
>
>
> This right here is part of the disconnect we have, and it's part of the
> reason why I wanted to invent specific terms to discuss these separate and
> distinct ideas. However, I don't really care what they're called, so long as
> the distinction is clear. So I'll try to use your language for them.
>
> The interface for `range::sort` is well specified. The range it is provided
> must conform to a specific set of requirements, and the function it is given
> (if any) must also conform to a specific set of requirements. That creates a
> contract between the callee and the caller.
>
> In order for a contract to work, this contract must be binding on both
> sides. The callee must provide at least the required interfaces, much like
> the person who derived from a base class must implement the pure-virtual
> members. However, the caller must also not attempt to perform any operations
> other than those for which the contract is valid. Much like the user of a
> base class cannot call functions which were not declared as part of the
> interface.
>
> There is absolutely no reason for an implementation of `range::sort` to
> violate its contract, to use its parameters in a way that violates the rules
> that govern its functionality. Indeed, those rules were created under the
> expectation that implementations will not need to do so.

I'm really not concerned about contract violations. What I'm concerned about
is code that doesn't violate a contract, but will be claimed to
violate a contract
by definition checking. Code like constrained templates using legacy templates
in their implementation. Or code like constrained templates using
tracing/debugging/telemetry
facilities. Such implementation details should not affect the
interface, but all definition
checking mechanisms described thus far make such interface effects unavoidable.


>
> An "interface constraint" is not a contract. It is merely a declaration of
> requirements on the user's part. A "definition constraint" is a real, live,
> compiler-verified contract between the caller and the callee.
>
> What I'm saying are the following:
>
> 1) We need to have both "interface constraints" and "definition
> constraints".

There seems to be much less need for the latter than the former.

> 2) We should declare them using similar syntax.

Fine by me.

> 3) We need to be able to use both in similar ways, likely with
> interoperation between them.

Depends on what those "similar ways" are. I want to opt in to
definition checking.

>
> 4) We need "definition constraints" to be part of the concepts syntax from
> day one, even if we don't actually require compilers to check the
> definitions. That way, people (including the Range TS) can write its
> concepts as definition constraints, with the expectation that, once compiler
> checking comes online, they will handle it.

I don't agree. These definition constraints, as they were in C++0x
Concepts or in
other vague descriptions of them as a mandatory always-on facility, don't work,
because they only ever work if every template ever used in the whole system
is constrained. That, as I said, is a useless non-starter.

>> That's an incorrect simplification. Concepts as proposed, and the
>> constraint language they use,
>> provide a means to write generic interfaces.
>
>
> Templates provide a means to write generic interfaces.

No they don't. They provide a means to write generic implementations,
but they provide
no means to write generic interfaces. Unless all you ever want an
interface to be able
to specify is whether something is a reference or a pointer. I don't
find that sufficient.

> Concepts TS simply provides a means to write explicitly constrained generic
> interfaces. Interfaces who's usage is verified by the compiler, and
> definitions for which can be SFINAE'd away based on their use. These are
> things we would have used `enable_if` and similar tools to handle before.
> Now we want to use Concepts TS for them.

Correct on that part.

> Boost Lambda was a library way to introduce lambda expressions. We got a
> replacement in the form of a language feature to do that. How is this
> different, exactly?

Perhaps it isn't. But my view on Concepts vs. enable_if and lambdas
vs. Boost.Lambda
is different than yours; my view is that the language facilities solve
the fundamental problem
better, not that they are 'replacements'. There's a subtle difference there.

>> enable_if can be abused
>> to do something remotely like that in a very
>> indirect manner,
> I'm curious: what other use for `enable_if` is there than constraining
> template instantiations?

The point is that enable_if is a fairly low-quality tool for
constraining templates. Especially
for constraining interface. Your choice of words "constraining
instantiations" is of course more
generic, and enable_if indeed does that, but it's not a good tool for
constraining interfaces,
which is a much smaller set of things than constraining instantiations.

>> > at P0225, all of the arguments made there in favor of Concepts TS talk
>> > about
>> > its use only as a replacement for `enable_if`. Concepts doesn't disturb
>> > the
>>
>> They talk about using Concepts to solve problems that are annoyingly
>> difficult to solve with enable_if. The only
>> aspect where Concepts are a replacement to enable_if is enable_if
>> being currently the only solution to any
>> such problems.
>
>
> And... it currently is. In C++14, if you want to constrain a template, you
> must do so with `enable_if` or some similar tool. So, I'm not sure what
> you're trying to say here.

Again, the paper talks about solutions to fundamental problems, not
about solutions
to replace abuses of enable_if.

>> The ability to write constrained interfaces for generic code without
>> disturbing deduction is of fundamental
>> importance. With enable_if, I need to resort to all sorts of brittle
>> nonsense to get to that destination.
>> With Concepts, I can write such interfaces directly, without separate
>> traits-wrapped logical combinations in
>> the declaration. I can emulate that goal to some extent; I recommend
>> looking at libstdc++'s <tuple> and the
>> tuple constructors for some examples. I have almost-predicates which
>> are constexpr functions. I still need
>> to wrap them inside an enable_if to constrain interfaces. With
>> Concepts, such wrapping becomes completely
>> unnecessary. I get constrained interfaces without the 'gymnastics'
>> mentioned below, and that's not such
>> syntactic sugar. I also get a well-defined and well-ordered constraint
>> evaluation model that makes it far easier to write constraints
>> and their combinations. And I get all that for both templates and
>> non-templates.
>
>
> At no point was I arguing against the the merits of "interface constraints";
> I was simply restating and summarizing your position within the larger body
> of thought on concepts. Specifically, that your points all matter only to
> the interface, not to the definition.

Well, perhaps that's because there's far more need to constrain
interfaces than there
is to constrain a definition. :)

>> > Concepts are about something more than merely being `enable_if` without
>> > the
>> > crappy syntax. Constraints simply say when a function/type may or may
>> > not
>> > exist. Concepts make a much stronger statement about the meaning of a
>> > piece
>> > of code. A concept is a constraint, but it constrains both halves of the
>> > code.
>>
>> Well, now you're talking about "Concepts" which may or may not
>> materialize.
>
>
> Sorry, but I don't read scare-quotes. Can you explain the difference between
> "Concepts" and scare-quotes "Concepts"?

Concepts as specified in the TS vs. Concepts that might also apply to
definitions.

>> The definition-checking half
>> certainly hasn't materialized yet in any form that would be viable.
>> And I have sufficient practical experience
>> and evidence that I know that "Concepts" that constrain "both halves"
>> of code so that they always constrain
>> both the interface and the definition, without letting me constrain
>> just the interface, are not worth the trouble.
>> They are a useless non-starter for practical purposes where
>> programmers need to deal with existing codebases, compatibility
>> and migration paths.
>
>
> I get that interface contracts aren't something you like to use. Please
> explain why that means nobody should be allowed to use contracts either.

I think you should've written 'definition' instead of 'interface'
there. I am not strongly
opposed to definition checking. What I'm opposed to is definition
checking that is always
on, and not being able to check just the interface. As I said, I have
plenty of evidence
that such mandatory definition checking will not work. It didn't work
before, and all
vague descriptions of how to supposedly do it with the new Concepts
suffer from the very
same problems as C++0x Concepts did.

>
>> > of static_if, a pure-constraint mechanism. Concepts-lite was a proposal
>> > that
>> > was made in response to a D-style static_if proposal (ironically,
>> > `constexpr
>> > if` is now more likely to see C++17 than Concepts TS). As such, it's
>> > primary
>> > focus is constraints, with full concepts as an optional extra.
>>
>> Revisionist history at its best. The work on Concepts Lite happened
>> separately and before
>> there ever was a proposal for a D-style static if for C++.
>
>
> But the only publicly available paper trail dates the first concepts-lite
> paper (N3580) 03/17/2013, while the first static_if papers (N3322 and N3329)
> at 12/11/2011 and 01/10/2012, both over a year before. Indeed, N3580 was

Well, if you read
http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3351.pdf,
you'll notice that it dates the Palo Alto meeting at August 4-9, 2011.
Concepts Lite
is the follow-up work of that.


> also released in the same mailing at N3618, which was a comparison between
> static_if and concepts-lite. So clearly, the authors of concepts-lite were
> aware of the static_if proposals and considered them competition.
>
> Maybe there were things happening behind closed doors. But from the
> information I have available, this is a reasonable description of the
> sequence of events.

Well, that latest description is remotely reasonable. Claiming that
Concepts Lite was (just) a response
to static if remains nonsense, and neither the paper trail or anything
else supports that conjecture,
you just pulled it out of your hat.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb2qtwiCrSArTbT7FYTk3Z2HaAZCciS2b7B0zV2-Eeonw%40mail.gmail.com.

.

------=_Part_103_1393515859.1464772705211
Content-Type: multipart/alternative;
 boundary="----=_Part_104_342734633.1464772705211"

------=_Part_104_342734633.1464772705211
Content-Type: text/plain; charset=UTF-8



> There is a semantic difference between *Constraints* and *Concepts*.
>

Actually I think that Constraints and Concepts are the same thing dressed
differently. The fact that something becomes a concept or not is the
author's choice.

*| Concepts* are about something more than merely being `enable_if` without
the crappy syntax.

In which way is this different from a constraint? A Concept, in my view, is
a constraint.

| I think the Concepts TS can provide both constraints and concepts. I can
see two ways of doing it:


Why should we complicate things that far if they are essentially the same
thing? I do not get your point about why they are different.

Another question I have is: do concepts enable any use case not enabled by
constraints (concepts-lite) in general?
Because type-checking everything is going very far on complicating things,
but, is this anything that has real use cases?
I say this from complete ignorance: can concepts do anything (full
concepts) that constraints (or concepts lite) cannot do
besides full checking in a real-case scenario? Checking templates fully
will also take compilation time, but not only that, it would complicate
implementations.
FWIW I am quite happy with the D approach + Concepts Lite. I am not sure
full concepts should ever be needed, or even if it is worth to make a
distinction,
since I feel that distinction (correct me if I am wrong) is arbitrary.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a8dba456-b892-4778-9728-05311d5fc261%40isocpp.org.

------=_Part_104_342734633.1464772705211
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">There is a semantic difference between <b>Constraints</b> and <b>C=
oncepts</b>.<br></div></blockquote><div dir=3D"ltr"><br>Actually I think th=
at Constraints and Concepts are the same thing dressed differently. The fac=
t that something becomes a concept or not is the author&#39;s choice.<br><b=
r><b>| Concepts</b> are about something more than merely being `enable_if` =
without the crappy syntax. <br><br>In which way is this different from a co=
nstraint? A Concept, in my view, is a constraint.<br><br>| I think the Conc=
epts TS can provide both constraints and concepts. I can see two ways of do=
ing it:<br><br><br>Why should we complicate things that far if they are ess=
entially the same thing? I do not get your point about why they are differe=
nt.<br><br>Another question I have is: do concepts enable any use case not =
enabled by constraints (concepts-lite) in general? <br>Because type-checkin=
g everything is going very far on complicating things, but, is this anythin=
g that has real use cases? <br>I say this from complete ignorance: can conc=
epts do anything (full concepts) that constraints (or concepts lite) cannot=
 do<br>besides full checking in a real-case scenario? Checking templates fu=
lly will also take compilation time, but not only that, it would complicate=
 implementations.<br>FWIW I am quite happy with the D approach + Concepts L=
ite. I am not sure full concepts should ever be needed, or even if it is wo=
rth to make a distinction,<br>since I feel that distinction (correct me if =
I am wrong) is arbitrary.<br><br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a8dba456-b892-4778-9728-05311d5fc261%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a8dba456-b892-4778-9728-05311d5fc261=
%40isocpp.org</a>.<br />

------=_Part_104_342734633.1464772705211--

------=_Part_103_1393515859.1464772705211--

.