------=_Part_14543_1306320811.1519661464926
Content-Type: multipart/alternative;
 boundary="----=_Part_14544_117551217.1519661464926"

------=_Part_14544_117551217.1519661464926
Content-Type: text/plain; charset="UTF-8"

Hi,

I believe it would be interesting to allow the users to state, when
declaring a type, that he aims at implementing a specific concept.

template<class T>
concept ValueType = requires() { T::value; }

struct A : concept C
{
};

//once the type has been instantiated check that the concepts are valid
with the new type.
//error: A doesn't satisfy the C concept. No A::value

I believe it would render the code easier to read by making explicit the
intent of the writer.
It would also make debugging easier in case of an error when writing an
implementation of a concept and
could be useful if/when the definition of a concept changed.

--
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/93e7e509-edf0-4df6-9b2f-555bba92a04a%40isocpp.org.

------=_Part_14544_117551217.1519661464926
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I believe it would be interesting t=
o allow the users to state, when declaring a type, that he aims at implemen=
ting a specific concept.</div><div><br></div><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
concept</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">ValueType</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> requires</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">value</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> A </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">concept</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> C<br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">//once the typ=
e has been instantiated </span><span style=3D"color: #800;" class=3D"styled=
-by-prettify">check that the concepts are valid with the new type.</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">//error: A doesn&#39;t sa=
tisfy the C concept. No A::value</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><div><br></div><div>I=
 believe it would render the code easier to read by making explicit the int=
ent of the writer.</div><div>It would also make debugging easier in case of=
 an error when writing an implementation of a concept and</div><div>could b=
e useful if/when the definition of a concept changed.</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/93e7e509-edf0-4df6-9b2f-555bba92a04a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/93e7e509-edf0-4df6-9b2f-555bba92a04a=
%40isocpp.org</a>.<br />

------=_Part_14544_117551217.1519661464926--

------=_Part_14543_1306320811.1519661464926--

.

On 26 February 2018 at 18:11,  <bastienpenava@gmail.com> wrote:
> Hi,
>
> I believe it would be interesting to allow the users to state, when
> declaring a type, that he aims at implementing a specific concept.
>
> template<class T>
> concept ValueType = requires() { T::value; }
>
> struct A : concept C
> {
> };
>
> //once the type has been instantiated check that the concepts are valid with
> the new type.
> //error: A doesn't satisfy the C concept. No A::value
>
> I believe it would render the code easier to read by making explicit the
> intent of the writer.
> It would also make debugging easier in case of an error when writing an
> implementation of a concept and
> could be useful if/when the definition of a concept changed.


struct A
{
};
static_assert(C<A>);

--
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/CAFk2RUYOMtQSR17Lr8C35sgjrSuK3yVYxx7iveYbv_tw4_YUNg%40mail.gmail.com.

.

------=_Part_14415_978119647.1519663063294
Content-Type: multipart/alternative;
 boundary="----=_Part_14416_1721795858.1519663063294"

------=_Part_14416_1721795858.1519663063294
Content-Type: text/plain; charset="UTF-8"

And what about if you want to implement a type that follows a concept, but
you're using non-member functions to implement certain aspects of that
concept? This wouldn't work, would it?

It's better to just use the obvious tool: `static_assert`. We don't need to
add a whole language feature for trivial convenience like this.

--
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/a1345907-f673-43f5-afb8-3ad064a0a6d6%40isocpp.org.

------=_Part_14416_1721795858.1519663063294
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>And what about if you want to implement a type that f=
ollows a concept, but you&#39;re using non-member functions to implement ce=
rtain aspects of that concept? This wouldn&#39;t work, would it?<br><br>It&=
#39;s better to just use the obvious tool: `static_assert`. We don&#39;t ne=
ed to add a whole language feature for trivial convenience like this.<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/a1345907-f673-43f5-afb8-3ad064a0a6d6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a1345907-f673-43f5-afb8-3ad064a0a6d6=
%40isocpp.org</a>.<br />

------=_Part_14416_1721795858.1519663063294--

------=_Part_14415_978119647.1519663063294--

.

------=_Part_15043_70308916.1519674496113
Content-Type: multipart/alternative;
 boundary="----=_Part_15044_1523856259.1519674496113"

------=_Part_15044_1523856259.1519674496113
Content-Type: text/plain; charset="UTF-8"

On Monday, February 26, 2018 at 5:37:43 PM UTC+1, Nicol Bolas wrote:
>
> And what about if you want to implement a type that follows a concept, but
> you're using non-member functions to implement certain aspects of that
> concept? This wouldn't work, would it?
>
> It's better to just use the obvious tool: `static_assert`. We don't need
> to add a whole language feature for trivial convenience like this.
>
For the non-member function yes it would work as long as you
friend-prototype/define said function.

As for static_assert, no it's not.
static_assert on an explicit concept call only triggers a "something went
wrong" level of informations: https://godbolt.org/g/5Hb7zP

The focus point though wasn't the static_assert part at all.
It was to explicitly state that a class is meant as an implementation of
some concepts for readability purposes
and to have some, possibly, interesting debugging side-effects coming from
that.

I agree though that a whole language feature would be overkill.
What about an attribute?

template<class T>
concept ValueType = requires() { T::value; }

[[concept C]] //can, or not, check if A satisfies C and issue either a
warning or error.
struct A
{
};

--
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/805d3933-0cf9-465f-906c-849ab25c7a63%40isocpp.org.

------=_Part_15044_1523856259.1519674496113
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, February 26, 2018 at 5:37:43 PM UTC+1, Nicol Bo=
las wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>And what about if you want to implement a type that follows a concept, bu=
t you&#39;re using non-member functions to implement certain aspects of tha=
t concept? This wouldn&#39;t work, would it?<br><br>It&#39;s better to just=
 use the obvious tool: `static_assert`. We don&#39;t need to add a whole la=
nguage feature for trivial convenience like this.<br></div></div></blockquo=
te><div>For the non-member function yes it would work as long as you friend=
-prototype/define said function.</div><div><br></div><div>As for static_ass=
ert, no it&#39;s not.<br></div><div>static_assert on an explicit concept ca=
ll only triggers a &quot;something went wrong&quot; level of informations:=
=C2=A0<a href=3D"https://godbolt.org/g/5Hb7zP">https://godbolt.org/g/5Hb7zP=
</a></div><div><br></div><div>The focus point though wasn&#39;t the static_=
assert part at all.</div><div>It was to explicitly state that a class is me=
ant as an implementation of some concepts for readability purposes</div><di=
v>and to have some, possibly, interesting debugging side-effects coming fro=
m that.=C2=A0<br></div><div><br></div><div>I agree though that a whole lang=
uage feature would be overkill.</div><div>What about an attribute?</div><di=
v><br></div><div><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">template</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">cla=
ss</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">concept</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">ValueType</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> requires</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">value</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">[[</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">concept</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> C</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]=
]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #800;" class=3D"styled-by-prettify">//can, or not, che=
ck if A satisfies C and issue either a warning or error.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> A<br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">};</span></div></code></div><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/805d3933-0cf9-465f-906c-849ab25c7a63%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/805d3933-0cf9-465f-906c-849ab25c7a63=
%40isocpp.org</a>.<br />

------=_Part_15044_1523856259.1519674496113--

------=_Part_15043_70308916.1519674496113--

.

--001a11482c20774e2705662304f7
Content-Type: text/plain; charset="UTF-8"

>
> As for static_assert, no it's not.
> static_assert on an explicit concept call only triggers a "something went
> wrong" level of informations: https://godbolt.org/g/5Hb7zP
>

That's a quality of implementation issue. I fully expect gcc to improve
this error message in the future.

I agree though that a whole language feature would be overkill.
> What about an attribute?
>

Why not use requires?

struct A requires C<A> {};

It looks more like a function constraint and doesn't require any weird
language feature. Also, attributes should not change the meaning of the
program if they are ignored, so using attributes is a non-starter.

--
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/CALmDwq1g4Sag%3D9c_eW3Qdy3KOUiHmhQTG1RB4fC1ZcgO6BfOtA%40mail.gmail.com.

--001a11482c20774e2705662304f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>As for static_assert, no i=
t&#39;s not.<br></div><div>static_assert on an explicit concept call only t=
riggers a &quot;something went wrong&quot; level of informations:=C2=A0<a h=
ref=3D"https://godbolt.org/g/5Hb7zP" target=3D"_blank">https://godbolt.<wbr=
>org/g/5Hb7zP</a></div></div></blockquote><div><br></div><div>That&#39;s a =
quality of implementation issue. I fully expect gcc to improve this error m=
essage in the future.</div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>I agree though that a whole language feature would be o=
verkill.</div><div>What about an attribute?</div></div></blockquote><div><b=
r></div><div>Why not use requires?</div><div><br></div><div>struct A requir=
es C&lt;A&gt; {};</div><div><br></div><div>It looks more like a function co=
nstraint and doesn&#39;t require any weird language feature. Also, attribut=
es should not change the meaning of the program if they are ignored, so usi=
ng attributes is a non-starter.</div></div></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/CALmDwq1g4Sag%3D9c_eW3Qdy3KOUiHmhQTG1=
RB4fC1ZcgO6BfOtA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1g4Sag%3=
D9c_eW3Qdy3KOUiHmhQTG1RB4fC1ZcgO6BfOtA%40mail.gmail.com</a>.<br />

--001a11482c20774e2705662304f7--

.

--001a113cd4f6f6e6bc0566241607
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I have a somewhat philosophical view on that.
If we have a syntax to tightly couple a concept to a satisfying
declaration, then is it still a concept ? Because it starts to look more
like regular interface / inheritance.

I see why one would want to document that a class satisfies a concept, but
when it stops to do so, does that means that the class is somehow broken
and should be ill-formed ?

I think the implicit nature of concepts is important and obviously
powerful. For this reason, I think the static_assert method is best.

While not directly comparable to concepts, Go interfaces are implicit and
it does seems to work  even on large codebases





Le lun. 26 f=C3=A9vr. 2018 =C3=A0 21:04, Nicolas Lesser <blitzrakete@gmail.=
com> a
=C3=A9crit :

> As for static_assert, no it's not.
>> static_assert on an explicit concept call only triggers a "something wen=
t
>> wrong" level of informations: https://godbolt.org/g/5Hb7zP
>>
>
> That's a quality of implementation issue. I fully expect gcc to improve
> this error message in the future.
>
> I agree though that a whole language feature would be overkill.
>> What about an attribute?
>>
>
> Why not use requires?
>
> struct A requires C<A> {};
>
> It looks more like a function constraint and doesn't require any weird
> language feature. Also, attributes should not change the meaning of the
> program if they are ignored, so using attributes is a non-starter.
>
> --
> 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/CALmDwq1g4Sa=
g%3D9c_eW3Qdy3KOUiHmhQTG1RB4fC1ZcgO6BfOtA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1g4S=
ag%3D9c_eW3Qdy3KOUiHmhQTG1RB4fC1ZcgO6BfOtA%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=20
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 e=
mail 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/CA%2BOm%2BSgAn%2BacLBxzeEGPCYRw4B2FLvm5G0ZQ2Htjt=
pi-%3D5sn0Q%40mail.gmail.com.

--001a113cd4f6f6e6bc0566241607
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div>I have a somewhat philosophical view on that.</di=
v><div>If we have a syntax to tightly couple a concept to a satisfying decl=
aration, then is it still a concept ? Because it starts to look more like r=
egular interface / inheritance.</div><div><br></div><div>I see why one woul=
d want to document that a class satisfies a concept, but when it stops to d=
o so, does that means that the class is somehow broken and should be ill-fo=
rmed ?</div><div><br></div><div>I think the implicit nature of concepts is =
important and obviously powerful. For this reason, I think the static_asser=
t method is best.</div><div><br></div><div>While not directly comparable to=
 concepts, Go interfaces are implicit and it does seems to work=C2=A0 even =
on large codebases</div><div><br></div><div><br></div><div><br></div><div><=
br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0lun. 26 f=
=C3=A9vr. 2018 =C3=A0=C2=A021:04, Nicolas Lesser &lt;<a href=3D"mailto:blit=
zrakete@gmail.com" target=3D"_blank">blitzrakete@gmail.com</a>&gt; a =C3=A9=
crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>As for static_assert, no it&#39;s not.<br></div><=
div>static_assert on an explicit concept call only triggers a &quot;somethi=
ng went wrong&quot; level of informations:=C2=A0<a href=3D"https://godbolt.=
org/g/5Hb7zP" target=3D"_blank">https://godbolt.org/g/5Hb7zP</a></div></div=
></blockquote><div><br></div></div></div></div><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>That&#39;s a quality of im=
plementation issue. I fully expect gcc to improve this error message in the=
 future.</div></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>I agree though that a whole language feature would be =
overkill.</div><div>What about an attribute?</div></div></blockquote><div><=
br></div></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><div>Why not use requires?</div><div><br></div><div>=
struct A requires C&lt;A&gt; {};</div><div><br></div><div>It looks more lik=
e a function constraint and doesn&#39;t require any weird language feature.=
 Also, attributes should not change the meaning of the program if they are =
ignored, so using attributes is a non-starter.</div></div></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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/CALmDwq1g4Sag%3D9c_eW3Qdy3KOUiHmhQTG1=
RB4fC1ZcgO6BfOtA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CALmDwq1g4Sag%3D9c_eW3Qdy3KOUiHmhQTG1RB4fC1ZcgO6BfOtA%40mail.gmail.c=
om</a>.<br>
</blockquote></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/CA%2BOm%2BSgAn%2BacLBxzeEGPCYRw4B2FLv=
m5G0ZQ2Htjtpi-%3D5sn0Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2=
BSgAn%2BacLBxzeEGPCYRw4B2FLvm5G0ZQ2Htjtpi-%3D5sn0Q%40mail.gmail.com</a>.<br=
 />

--001a113cd4f6f6e6bc0566241607--

.