------=_Part_379_172334612.1485328872968
Content-Type: multipart/alternative;
 boundary="----=_Part_380_409691858.1485328872968"

------=_Part_380_409691858.1485328872968
Content-Type: text/plain; charset=UTF-8

Problem definition: Most projects have a document called 'Coding standards'
that represent rules for how the programmers should use C++. Most of these
documents basically define a subset of C++ that is enforced for that
project. But the enforcement is usually done at the code review level where
people point out when some C++ usage violates the rules. Since these code
reviews aren't always as thorough as they should be, or there aren't any
code reviews due to other constraints, wouldn't it be nice if the compiler
could enforce these rules and wouldn't let a piece of code compile when the
rules of the coding standard have been violated?

Solution (proposed): Since C++ has object oriented support, I thought of
something similar. You have a base class that represents the full set of
the C++ standard. In order to enforce this class you don't have to do
anything, so all C++ projects out there can choose to implement this
enforcement in their own time if they choose to. This base class can be
derived to add rules: for example you add the rule that goto is banned.
Then, you add something that would look like a preprocessor #ifdef - #endif
block that means that for that part of code the subclass rules are
enforced, thus any goto gets flagged and not allowed. These subclasses can
be derived further and more and more rules be enforced. With each
derivation, more things from the C++ standard are removed. So you only
substract with each derived class, you cannot add a new rule that goto is
allowed after its superclass banned it.

But, at the code level, the subclassing is not enforced, you can have a
block that bans goto and inside have a subblock that allows it temporarily.
The basic idea isn't to have a million of these classes enforcing a billion
rules but to be able to divide the codebase in things like high-level code
and low-level code. In the high level portion you aren't allowed to use
things like pointer hacking, or naked pointers, while in the low level
portion everything, or most things, are allowed. This way, if somebody is
trying to modify some piece of code that he has never seen before, he
doesn't need to guess the way that code should be written in that module
just by looking at the neighbouring code, but can actually jump to the
class that defines the rules and can read and follow them from there. And
if he doesn't follow them he can't compile. If he chooses to create a
subblock where he allows himself to do what he pleases, that is something
that can be seen easier in the repository. Since creating new rules is
basically creating new headers (or maybe a new type of file, special for
these rules), it's easier to control who creates the rules in a team so
that not everybody can use and create whatever rule he wants whenever he
wants (that would defeat the purpose of trying to enforce the coding
standard).

Since I've heard that the module concept is coming to the next version of
C++, maybe this would be a good idea to enforce the coding standard at the
module level.

Right now I am only interested to see the reaction for this proposal as I
haven't mapped out the nitty gritty details and see what corners this
design would force you into, so what do you think about the idea of finding
a way to enforce a subset of C++ at the compiler level?

--
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/7b9f1b29-cd23-4a12-9711-90d69de78669%40isocpp.org.

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

<div dir=3D"ltr">Problem definition: Most projects have a document called &=
#39;Coding standards&#39; that represent rules for how the programmers shou=
ld use C++. Most of these documents basically define a subset of C++ that i=
s enforced for that project. But the enforcement is usually done at the cod=
e review level where people point out when some C++ usage violates the rule=
s. Since these code reviews aren&#39;t always as thorough as they should be=
, or there aren&#39;t any code reviews due to other constraints, wouldn&#39=
;t it be nice if the compiler could enforce these rules and wouldn&#39;t le=
t a piece of code compile when the rules of the coding standard have been v=
iolated?<div><br></div><div>Solution (proposed): Since C++ has object orien=
ted support, I thought of something similar. You have a base class that rep=
resents the full set of the C++ standard. In order to enforce this class yo=
u don&#39;t have to do anything, so all C++ projects out there can choose t=
o implement this enforcement in their own time if they choose to. This base=
 class can be derived to add rules: for example you add the rule that goto =
is banned. Then, you add something that would look like a preprocessor #ifd=
ef - #endif block that means that for that part of code the subclass rules =
are enforced, thus any goto gets flagged and not allowed. These subclasses =
can be derived further and more and more rules be enforced. With each deriv=
ation, more things from the C++ standard are removed. So you only substract=
 with each derived class, you cannot add a new rule that goto is allowed af=
ter its superclass banned it.</div><div><br></div><div>But, at the code lev=
el, the subclassing is not enforced, you can have a block that bans goto an=
d inside have a subblock that allows it temporarily. The basic idea isn&#39=
;t to have a million of these classes enforcing a billion rules but to be a=
ble to divide the codebase in things like high-level code and low-level cod=
e. In the high level portion you aren&#39;t allowed to use things like poin=
ter hacking, or naked pointers, while in the low level portion everything, =
or most things, are allowed. This way, if somebody is trying to modify some=
 piece of code that he has never seen before, he doesn&#39;t need to guess =
the way that code should be written in that module just by looking at the n=
eighbouring code, but can actually jump to the class that defines the rules=
 and can read and follow them from there. And if he doesn&#39;t follow them=
 he can&#39;t compile. If he chooses to create a subblock where he allows h=
imself to do what he pleases, that is something that can be seen easier in =
the repository. Since creating new rules is basically creating new headers =
(or maybe a new type of file, special for these rules), it&#39;s easier to =
control who creates the rules in a team so that not everybody can use and c=
reate whatever rule he wants whenever he wants (that would defeat the purpo=
se of trying to enforce the coding standard).=C2=A0</div><div><br></div><di=
v>Since I&#39;ve heard that the module concept is coming to the next versio=
n of C++, maybe this would be a good idea to enforce the coding standard at=
 the module level.</div><div><br></div><div>Right now I am only interested =
to see the reaction for this proposal as I haven&#39;t mapped out the nitty=
 gritty details and see what corners this design would force you into, so w=
hat do you think about the idea of finding a way to enforce a subset of C++=
 at the compiler level?</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/7b9f1b29-cd23-4a12-9711-90d69de78669%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7b9f1b29-cd23-4a12-9711-90d69de78669=
%40isocpp.org</a>.<br />

------=_Part_380_409691858.1485328872968--

------=_Part_379_172334612.1485328872968--

.

--Apple-Mail-B5FA731E-F132-45CE-9229-270E9985E0DB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



> On 25 Jan 2017, at 07:21, sebastian.bugiu.reloaded@gmail.com wrote:
>=20
> Problem definition: Most projects have a document called 'Coding standard=
s' that represent rules for how the programmers should use C++. Most of the=
se documents basically define a subset of C++ that is enforced for that pro=
ject. But the enforcement is usually done at the code review level where pe=
ople point out when some C++ usage violates the rules. Since these code rev=
iews aren't always as thorough as they should be, or there aren't any code =
reviews due to other constraints, wouldn't it be nice if the compiler could=
 enforce these rules and wouldn't let a piece of code compile when the rule=
s of the coding standard have been violated?
>=20
> Solution (proposed): Since C++ has object oriented support, I thought of =
something similar. You have a base class that represents the full set of th=
e C++ standard. In order to enforce this class you don't have to do anythin=
g, so all C++ projects out there can choose to implement this enforcement i=
n their own time if they choose to. This base class can be derived to add r=
ules: for example you add the rule that goto is banned. Then, you add somet=
hing that would look like a preprocessor #ifdef - #endif block that means t=
hat for that part of code the subclass rules are enforced, thus any goto ge=
ts flagged and not allowed. These subclasses can be derived further and mor=
e and more rules be enforced. With each derivation, more things from the C+=
+ standard are removed. So you only substract with each derived class, you =
cannot add a new rule that goto is allowed after its superclass banned it.
>=20
> But, at the code level, the subclassing is not enforced, you can have a b=
lock that bans goto and inside have a subblock that allows it temporarily. =
The basic idea isn't to have a million of these classes enforcing a billion=
 rules but to be able to divide the codebase in things like high-level code=
 and low-level code. In the high level portion you aren't allowed to use th=
ings like pointer hacking, or naked pointers, while in the low level portio=
n everything, or most things, are allowed. This way, if somebody is trying =
to modify some piece of code that he has never seen before, he doesn't need=
 to guess the way that code should be written in that module just by lookin=
g at the neighbouring code, but can actually jump to the class that defines=
 the rules and can read and follow them from there. And if he doesn't follo=
w them he can't compile. If he chooses to create a subblock where he allows=
 himself to do what he pleases, that is something that can be seen easier i=
n the repository. Since creating new rules is basically creating new header=
s (or maybe a new type of file, special for these rules), it's easier to co=
ntrol who creates the rules in a team so that not everybody can use and cre=
ate whatever rule he wants whenever he wants (that would defeat the purpose=
 of trying to enforce the coding standard).=20
>=20
> Since I've heard that the module concept is coming to the next version of=
 C++, maybe this would be a good idea to enforce the coding standard at the=
 module level.
>=20
> Right now I am only interested to see the reaction for this proposal as I=
 haven't mapped out the nitty gritty details and see what corners this desi=
gn would force you into, so what do you think about the idea of finding a w=
ay to enforce a subset of C++ at the compiler level?
This feels more like a tooling issue than a language issue to me.

I've used clang-tidy=20
http://clang.llvm.org/extra/clang-tidy/ to enforce (parts of) in-house styl=
e guides with great success. Would that do what you need?

clang-tidy config files can be set in different places in the code to apply=
 different checks in different places.

Regards

Jon


> --=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=
 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/isoc=
pp.org/d/msgid/std-proposals/7b9f1b29-cd23-4a12-9711-90d69de78669%40isocpp.=
org.

--=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/EFC67D43-B5EC-47B2-8047-87DE74EBC183%40gmail.com=
..

--Apple-Mail-B5FA731E-F132-45CE-9229-270E9985E0DB
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div><br></div><div><br>On 2=
5 Jan 2017, at 07:21, <a href=3D"mailto:sebastian.bugiu.reloaded@gmail.com"=
>sebastian.bugiu.reloaded@gmail.com</a> wrote:<br><br></div><blockquote typ=
e=3D"cite"><div><div dir=3D"ltr">Problem definition: Most projects have a d=
ocument called 'Coding standards' that represent rules for how the programm=
ers should use C++. Most of these documents basically define a subset of C+=
+ that is enforced for that project. But the enforcement is usually done at=
 the code review level where people point out when some C++ usage violates =
the rules. Since these code reviews aren't always as thorough as they shoul=
d be, or there aren't any code reviews due to other constraints, wouldn't i=
t be nice if the compiler could enforce these rules and wouldn't let a piec=
e of code compile when the rules of the coding standard have been violated?=
<div><br></div><div>Solution (proposed): Since C++ has object oriented supp=
ort, I thought of something similar. You have a base class that represents =
the full set of the C++ standard. In order to enforce this class you don't =
have to do anything, so all C++ projects out there can choose to implement =
this enforcement in their own time if they choose to. This base class can b=
e derived to add rules: for example you add the rule that goto is banned. T=
hen, you add something that would look like a preprocessor #ifdef - #endif =
block that means that for that part of code the subclass rules are enforced=
, thus any goto gets flagged and not allowed. These subclasses can be deriv=
ed further and more and more rules be enforced. With each derivation, more =
things from the C++ standard are removed. So you only substract with each d=
erived class, you cannot add a new rule that goto is allowed after its supe=
rclass banned it.</div><div><br></div><div>But, at the code level, the subc=
lassing is not enforced, you can have a block that bans goto and inside hav=
e a subblock that allows it temporarily. The basic idea isn't to have a mil=
lion of these classes enforcing a billion rules but to be able to divide th=
e codebase in things like high-level code and low-level code. In the high l=
evel portion you aren't allowed to use things like pointer hacking, or nake=
d pointers, while in the low level portion everything, or most things, are =
allowed. This way, if somebody is trying to modify some piece of code that =
he has never seen before, he doesn't need to guess the way that code should=
 be written in that module just by looking at the neighbouring code, but ca=
n actually jump to the class that defines the rules and can read and follow=
 them from there. And if he doesn't follow them he can't compile. If he cho=
oses to create a subblock where he allows himself to do what he pleases, th=
at is something that can be seen easier in the repository. Since creating n=
ew rules is basically creating new headers (or maybe a new type of file, sp=
ecial for these rules), it's easier to control who creates the rules in a t=
eam so that not everybody can use and create whatever rule he wants wheneve=
r he wants (that would defeat the purpose of trying to enforce the coding s=
tandard).&nbsp;</div><div><br></div><div>Since I've heard that the module c=
oncept is coming to the next version of C++, maybe this would be a good ide=
a to enforce the coding standard at the module level.</div><div><br></div><=
div>Right now I am only interested to see the reaction for this proposal as=
 I haven't mapped out the nitty gritty details and see what corners this de=
sign would force you into, so what do you think about the idea of finding a=
 way to enforce a subset of C++ at the compiler level?</div></div>

<p></p>

</div></blockquote><div>This feels more like a tooling issue than a languag=
e issue to me.</div><div><br></div><div>I've used clang-tidy&nbsp;</div><di=
v><a href=3D"http://clang.llvm.org/extra/clang-tidy/">http://clang.llvm.org=
/extra/clang-tidy/</a>&nbsp;to enforce (parts of) in-house style guides wit=
h great success. Would that do what you need?</div><div><br></div><div>clan=
g-tidy config files can be set in different places in the code to apply dif=
ferent checks in different places.</div><div><br></div><div>Regards</div><d=
iv><br></div><div>Jon</div><div><br></div><br><blockquote type=3D"cite"><di=
v>-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" 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/7b9f1b29-cd23-4a12-9711-90d69de78669%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/7b9f1b29-cd23-4a12-9711-90d69de7=
8669%40isocpp.org</a>.<br>
</div></blockquote></body></html>

<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/EFC67D43-B5EC-47B2-8047-87DE74EBC183%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/EFC67D43-B5EC-47B2-8047-87DE74EBC183%=
40gmail.com</a>.<br />

--Apple-Mail-B5FA731E-F132-45CE-9229-270E9985E0DB--

.

------=_Part_2009_142267269.1485340097948
Content-Type: multipart/alternative;
 boundary="----=_Part_2010_147124355.1485340097949"

------=_Part_2010_147124355.1485340097949
Content-Type: text/plain; charset=UTF-8

I know tools like static analysis and lint work, but they are not
universal. Of course, keeping it outside the compiler is neater because it
separates things, but what I was proposing was a universal lint of sorts.
Microsoft has a linter, Clang has one, but the problem is learning each of
these tools when switching projects and also that I am not sure that you
can enforce these hierarchies depending on modules like I am talking about.
It would make C++ more 'portable' in a way.

On Wednesday, January 25, 2017 at 9:56:27 AM UTC+2, Jonathan Coe wrote:
>
>
>
> On 25 Jan 2017, at 07:21, sebastian.bu...@gmail.com <javascript:> wrote:
>
> Problem definition: Most projects have a document called 'Coding
> standards' that represent rules for how the programmers should use C++.
> Most of these documents basically define a subset of C++ that is enforced
> for that project. But the enforcement is usually done at the code review
> level where people point out when some C++ usage violates the rules. Since
> these code reviews aren't always as thorough as they should be, or there
> aren't any code reviews due to other constraints, wouldn't it be nice if
> the compiler could enforce these rules and wouldn't let a piece of code
> compile when the rules of the coding standard have been violated?
>
> Solution (proposed): Since C++ has object oriented support, I thought of
> something similar. You have a base class that represents the full set of
> the C++ standard. In order to enforce this class you don't have to do
> anything, so all C++ projects out there can choose to implement this
> enforcement in their own time if they choose to. This base class can be
> derived to add rules: for example you add the rule that goto is banned.
> Then, you add something that would look like a preprocessor #ifdef - #endif
> block that means that for that part of code the subclass rules are
> enforced, thus any goto gets flagged and not allowed. These subclasses can
> be derived further and more and more rules be enforced. With each
> derivation, more things from the C++ standard are removed. So you only
> substract with each derived class, you cannot add a new rule that goto is
> allowed after its superclass banned it.
>
> But, at the code level, the subclassing is not enforced, you can have a
> block that bans goto and inside have a subblock that allows it temporarily.
> The basic idea isn't to have a million of these classes enforcing a billion
> rules but to be able to divide the codebase in things like high-level code
> and low-level code. In the high level portion you aren't allowed to use
> things like pointer hacking, or naked pointers, while in the low level
> portion everything, or most things, are allowed. This way, if somebody is
> trying to modify some piece of code that he has never seen before, he
> doesn't need to guess the way that code should be written in that module
> just by looking at the neighbouring code, but can actually jump to the
> class that defines the rules and can read and follow them from there. And
> if he doesn't follow them he can't compile. If he chooses to create a
> subblock where he allows himself to do what he pleases, that is something
> that can be seen easier in the repository. Since creating new rules is
> basically creating new headers (or maybe a new type of file, special for
> these rules), it's easier to control who creates the rules in a team so
> that not everybody can use and create whatever rule he wants whenever he
> wants (that would defeat the purpose of trying to enforce the coding
> standard).
>
> Since I've heard that the module concept is coming to the next version of
> C++, maybe this would be a good idea to enforce the coding standard at the
> module level.
>
> Right now I am only interested to see the reaction for this proposal as I
> haven't mapped out the nitty gritty details and see what corners this
> design would force you into, so what do you think about the idea of finding
> a way to enforce a subset of C++ at the compiler level?
>
> This feels more like a tooling issue than a language issue to me.
>
> I've used clang-tidy
> http://clang.llvm.org/extra/clang-tidy/ to enforce (parts of) in-house
> style guides with great success. Would that do what you need?
>
> clang-tidy config files can be set in different places in the code to
> apply different checks in different places.
>
> Regards
>
> Jon
>
>
> --
> 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-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b9f1b29-cd23-4a12-9711-90d69de78669%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b9f1b29-cd23-4a12-9711-90d69de78669%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
>

--
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/be2c389a-4624-43d3-8205-72c364e1c632%40isocpp.org.

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

<div dir=3D"ltr">I know tools like static analysis and lint work, but they =
are not universal. Of course, keeping it outside the compiler is neater bec=
ause it separates things, but what I was proposing was a universal lint of =
sorts. Microsoft has a linter, Clang has one, but the problem is learning e=
ach of these tools when switching projects and also that I am not sure that=
 you can enforce these hierarchies depending on modules like I am talking a=
bout. It would make C++ more &#39;portable&#39; in a way.<br><br>On Wednesd=
ay, January 25, 2017 at 9:56:27 AM UTC+2, Jonathan Coe wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div></div><div><br></div>=
<div><br>On 25 Jan 2017, at 07:21, <a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"5BqKr0VLAgAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;j=
avascript:&#39;;return true;">sebastian.bu...@<wbr>gmail.com</a> wrote:<br>=
<br></div><blockquote type=3D"cite"><div><div dir=3D"ltr">Problem definitio=
n: Most projects have a document called &#39;Coding standards&#39; that rep=
resent rules for how the programmers should use C++. Most of these document=
s basically define a subset of C++ that is enforced for that project. But t=
he enforcement is usually done at the code review level where people point =
out when some C++ usage violates the rules. Since these code reviews aren&#=
39;t always as thorough as they should be, or there aren&#39;t any code rev=
iews due to other constraints, wouldn&#39;t it be nice if the compiler coul=
d enforce these rules and wouldn&#39;t let a piece of code compile when the=
 rules of the coding standard have been violated?<div><br></div><div>Soluti=
on (proposed): Since C++ has object oriented support, I thought of somethin=
g similar. You have a base class that represents the full set of the C++ st=
andard. In order to enforce this class you don&#39;t have to do anything, s=
o all C++ projects out there can choose to implement this enforcement in th=
eir own time if they choose to. This base class can be derived to add rules=
: for example you add the rule that goto is banned. Then, you add something=
 that would look like a preprocessor #ifdef - #endif block that means that =
for that part of code the subclass rules are enforced, thus any goto gets f=
lagged and not allowed. These subclasses can be derived further and more an=
d more rules be enforced. With each derivation, more things from the C++ st=
andard are removed. So you only substract with each derived class, you cann=
ot add a new rule that goto is allowed after its superclass banned it.</div=
><div><br></div><div>But, at the code level, the subclassing is not enforce=
d, you can have a block that bans goto and inside have a subblock that allo=
ws it temporarily. The basic idea isn&#39;t to have a million of these clas=
ses enforcing a billion rules but to be able to divide the codebase in thin=
gs like high-level code and low-level code. In the high level portion you a=
ren&#39;t allowed to use things like pointer hacking, or naked pointers, wh=
ile in the low level portion everything, or most things, are allowed. This =
way, if somebody is trying to modify some piece of code that he has never s=
een before, he doesn&#39;t need to guess the way that code should be writte=
n in that module just by looking at the neighbouring code, but can actually=
 jump to the class that defines the rules and can read and follow them from=
 there. And if he doesn&#39;t follow them he can&#39;t compile. If he choos=
es to create a subblock where he allows himself to do what he pleases, that=
 is something that can be seen easier in the repository. Since creating new=
 rules is basically creating new headers (or maybe a new type of file, spec=
ial for these rules), it&#39;s easier to control who creates the rules in a=
 team so that not everybody can use and create whatever rule he wants whene=
ver he wants (that would defeat the purpose of trying to enforce the coding=
 standard).=C2=A0</div><div><br></div><div>Since I&#39;ve heard that the mo=
dule concept is coming to the next version of C++, maybe this would be a go=
od idea to enforce the coding standard at the module level.</div><div><br><=
/div><div>Right now I am only interested to see the reaction for this propo=
sal as I haven&#39;t mapped out the nitty gritty details and see what corne=
rs this design would force you into, so what do you think about the idea of=
 finding a way to enforce a subset of C++ at the compiler level?</div></div=
>

<p></p>

</div></blockquote><div>This feels more like a tooling issue than a languag=
e issue to me.</div><div><br></div><div>I&#39;ve used clang-tidy=C2=A0</div=
><div><a href=3D"http://clang.llvm.org/extra/clang-tidy/" target=3D"_blank"=
 rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url=
?q\x3dhttp%3A%2F%2Fclang.llvm.org%2Fextra%2Fclang-tidy%2F\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNEuEWTbnZmQnIymRoRjJMSUXMRBYw&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fclang.l=
lvm.org%2Fextra%2Fclang-tidy%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEuE=
WTbnZmQnIymRoRjJMSUXMRBYw&#39;;return true;">http://clang.llvm.org/extra/<w=
br>clang-tidy/</a>=C2=A0to enforce (parts of) in-house style guides with gr=
eat success. Would that do what you need?</div><div><br></div><div>clang-ti=
dy config files can be set in different places in the code to apply differe=
nt checks in different places.</div><div><br></div><div>Regards</div><div><=
br></div><div>Jon</div><div><br></div><br><blockquote type=3D"cite"><div>--=
 <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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
5BqKr0VLAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"5BqKr0VLAgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@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/7b9f1b29-cd23-4a12-9711-90d69de78669%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/7b9f1b29-cd23-4a12-9711-90d69de78669%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/7b9f1b29-cd23-4a12-9711-90d69de78669%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/7b9f1b29-cd23-4a12-<wbr>9711-=
90d69de78669%40isocpp.org</a><wbr>.<br>
</div></blockquote></div></blockquote></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/be2c389a-4624-43d3-8205-72c364e1c632%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/be2c389a-4624-43d3-8205-72c364e1c632=
%40isocpp.org</a>.<br />

------=_Part_2010_147124355.1485340097949--

------=_Part_2009_142267269.1485340097948--

.

As Jonathan pointed out, this is a tooling issue. I do not see any
reason to let this be part of the C++ standard.
Imagine the amount of work needed by the standard committee to sort
out what is good and what is not a good part of C++. Do we really want
the committee to focus on stuff like that - unlikely to be agreed upon
before 2026 - instead of using its time on valuable stuff such as
coroutines, modules and concepts?
And frankly, what is the value of such a feature? Just use clang or
other tools (for goto, grep comes to mind) to detect violations of a
coding standard.

/Peter

On Wed, Jan 25, 2017 at 11:28 AM,  <sebastian.bugiu.reloaded@gmail.com> wrote:
> I know tools like static analysis and lint work, but they are not universal.
> Of course, keeping it outside the compiler is neater because it separates
> things, but what I was proposing was a universal lint of sorts. Microsoft
> has a linter, Clang has one, but the problem is learning each of these tools
> when switching projects and also that I am not sure that you can enforce
> these hierarchies depending on modules like I am talking about. It would
> make C++ more 'portable' in a way.
>
> On Wednesday, January 25, 2017 at 9:56:27 AM UTC+2, Jonathan Coe wrote:
>>
>>
>>
>> On 25 Jan 2017, at 07:21, sebastian.bu...@gmail.com wrote:
>>
>> Problem definition: Most projects have a document called 'Coding
>> standards' that represent rules for how the programmers should use C++. Most
>> of these documents basically define a subset of C++ that is enforced for
>> that project. But the enforcement is usually done at the code review level
>> where people point out when some C++ usage violates the rules. Since these
>> code reviews aren't always as thorough as they should be, or there aren't
>> any code reviews due to other constraints, wouldn't it be nice if the
>> compiler could enforce these rules and wouldn't let a piece of code compile
>> when the rules of the coding standard have been violated?
>>
>> Solution (proposed): Since C++ has object oriented support, I thought of
>> something similar. You have a base class that represents the full set of the
>> C++ standard. In order to enforce this class you don't have to do anything,
>> so all C++ projects out there can choose to implement this enforcement in
>> their own time if they choose to. This base class can be derived to add
>> rules: for example you add the rule that goto is banned. Then, you add
>> something that would look like a preprocessor #ifdef - #endif block that
>> means that for that part of code the subclass rules are enforced, thus any
>> goto gets flagged and not allowed. These subclasses can be derived further
>> and more and more rules be enforced. With each derivation, more things from
>> the C++ standard are removed. So you only substract with each derived class,
>> you cannot add a new rule that goto is allowed after its superclass banned
>> it.
>>
>> But, at the code level, the subclassing is not enforced, you can have a
>> block that bans goto and inside have a subblock that allows it temporarily.
>> The basic idea isn't to have a million of these classes enforcing a billion
>> rules but to be able to divide the codebase in things like high-level code
>> and low-level code. In the high level portion you aren't allowed to use
>> things like pointer hacking, or naked pointers, while in the low level
>> portion everything, or most things, are allowed. This way, if somebody is
>> trying to modify some piece of code that he has never seen before, he
>> doesn't need to guess the way that code should be written in that module
>> just by looking at the neighbouring code, but can actually jump to the class
>> that defines the rules and can read and follow them from there. And if he
>> doesn't follow them he can't compile. If he chooses to create a subblock
>> where he allows himself to do what he pleases, that is something that can be
>> seen easier in the repository. Since creating new rules is basically
>> creating new headers (or maybe a new type of file, special for these rules),
>> it's easier to control who creates the rules in a team so that not everybody
>> can use and create whatever rule he wants whenever he wants (that would
>> defeat the purpose of trying to enforce the coding standard).
>>
>> Since I've heard that the module concept is coming to the next version of
>> C++, maybe this would be a good idea to enforce the coding standard at the
>> module level.
>>
>> Right now I am only interested to see the reaction for this proposal as I
>> haven't mapped out the nitty gritty details and see what corners this design
>> would force you into, so what do you think about the idea of finding a way
>> to enforce a subset of C++ at the compiler level?
>>
>> This feels more like a tooling issue than a language issue to me.
>>
>> I've used clang-tidy
>> http://clang.llvm.org/extra/clang-tidy/ to enforce (parts of) in-house
>> style guides with great success. Would that do what you need?
>>
>> clang-tidy config files can be set in different places in the code to
>> apply different checks in different places.
>>
>> Regards
>>
>> Jon
>>
>>
>> --
>> 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-proposal...@isocpp.org.
>> To post to this group, send email to std-pr...@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b9f1b29-cd23-4a12-9711-90d69de78669%40isocpp.org.
>
> --
> 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/be2c389a-4624-43d3-8205-72c364e1c632%40isocpp.org.

--
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/CANPtknxAK3VcmdGUfukk9%2Bc_55UDHoPcDyn2_CvoeovBLLPwUg%40mail.gmail.com.

.

------=_Part_54_567997480.1485379685844
Content-Type: multipart/alternative;
 boundary="----=_Part_55_1523911940.1485379685844"

------=_Part_55_1523911940.1485379685844
Content-Type: text/plain; charset=UTF-8

Nobody is asking the committee to sort what is good or what is bad in C++.
The whole idea is to allow the user to select that for himself what he
considers valuable. goto was just an example, the idea was to have
something more general. grep wouldn't help since it would select all
instances without knowing which should be accepted and which shouldn't.
Just use clang? Not everybody uses clang. Not everybody considers clang
good. The tools can't detect if a particular thing from the coding standard
is allowed in some piece of code or not. They only detect at project level.
And that was my whole idea, give more granularity at code level. Which
would require the thing to be implemented in the compiler. Which probably
would mean that it should be in the C++ standard.

On Wednesday, January 25, 2017 at 1:37:50 PM UTC+2, Peter Koch Larsen wrote:
>
> As Jonathan pointed out, this is a tooling issue. I do not see any
> reason to let this be part of the C++ standard.
> Imagine the amount of work needed by the standard committee to sort
> out what is good and what is not a good part of C++. Do we really want
> the committee to focus on stuff like that - unlikely to be agreed upon
> before 2026 - instead of using its time on valuable stuff such as
> coroutines, modules and concepts?
> And frankly, what is the value of such a feature? Just use clang or
> other tools (for goto, grep comes to mind) to detect violations of a
> coding standard.
>
> /Peter
>
> On Wed, Jan 25, 2017 at 11:28 AM,  <sebastian.bu...@gmail.com
> <javascript:>> wrote:
> > I know tools like static analysis and lint work, but they are not
> universal.
> > Of course, keeping it outside the compiler is neater because it
> separates
> > things, but what I was proposing was a universal lint of sorts.
> Microsoft
> > has a linter, Clang has one, but the problem is learning each of these
> tools
> > when switching projects and also that I am not sure that you can enforce
> > these hierarchies depending on modules like I am talking about. It would
> > make C++ more 'portable' in a way.
> >
> > On Wednesday, January 25, 2017 at 9:56:27 AM UTC+2, Jonathan Coe wrote:
> >>
> >>
> >>
> >> On 25 Jan 2017, at 07:21, sebastian.bu...@gmail.com wrote:
> >>
> >> Problem definition: Most projects have a document called 'Coding
> >> standards' that represent rules for how the programmers should use C++.
> Most
> >> of these documents basically define a subset of C++ that is enforced
> for
> >> that project. But the enforcement is usually done at the code review
> level
> >> where people point out when some C++ usage violates the rules. Since
> these
> >> code reviews aren't always as thorough as they should be, or there
> aren't
> >> any code reviews due to other constraints, wouldn't it be nice if the
> >> compiler could enforce these rules and wouldn't let a piece of code
> compile
> >> when the rules of the coding standard have been violated?
> >>
> >> Solution (proposed): Since C++ has object oriented support, I thought
> of
> >> something similar. You have a base class that represents the full set
> of the
> >> C++ standard. In order to enforce this class you don't have to do
> anything,
> >> so all C++ projects out there can choose to implement this enforcement
> in
> >> their own time if they choose to. This base class can be derived to add
> >> rules: for example you add the rule that goto is banned. Then, you add
> >> something that would look like a preprocessor #ifdef - #endif block
> that
> >> means that for that part of code the subclass rules are enforced, thus
> any
> >> goto gets flagged and not allowed. These subclasses can be derived
> further
> >> and more and more rules be enforced. With each derivation, more things
> from
> >> the C++ standard are removed. So you only substract with each derived
> class,
> >> you cannot add a new rule that goto is allowed after its superclass
> banned
> >> it.
> >>
> >> But, at the code level, the subclassing is not enforced, you can have a
> >> block that bans goto and inside have a subblock that allows it
> temporarily.
> >> The basic idea isn't to have a million of these classes enforcing a
> billion
> >> rules but to be able to divide the codebase in things like high-level
> code
> >> and low-level code. In the high level portion you aren't allowed to use
> >> things like pointer hacking, or naked pointers, while in the low level
> >> portion everything, or most things, are allowed. This way, if somebody
> is
> >> trying to modify some piece of code that he has never seen before, he
> >> doesn't need to guess the way that code should be written in that
> module
> >> just by looking at the neighbouring code, but can actually jump to the
> class
> >> that defines the rules and can read and follow them from there. And if
> he
> >> doesn't follow them he can't compile. If he chooses to create a
> subblock
> >> where he allows himself to do what he pleases, that is something that
> can be
> >> seen easier in the repository. Since creating new rules is basically
> >> creating new headers (or maybe a new type of file, special for these
> rules),
> >> it's easier to control who creates the rules in a team so that not
> everybody
> >> can use and create whatever rule he wants whenever he wants (that would
> >> defeat the purpose of trying to enforce the coding standard).
> >>
> >> Since I've heard that the module concept is coming to the next version
> of
> >> C++, maybe this would be a good idea to enforce the coding standard at
> the
> >> module level.
> >>
> >> Right now I am only interested to see the reaction for this proposal as
> I
> >> haven't mapped out the nitty gritty details and see what corners this
> design
> >> would force you into, so what do you think about the idea of finding a
> way
> >> to enforce a subset of C++ at the compiler level?
> >>
> >> This feels more like a tooling issue than a language issue to me.
> >>
> >> I've used clang-tidy
> >> http://clang.llvm.org/extra/clang-tidy/ to enforce (parts of) in-house
> >> style guides with great success. Would that do what you need?
> >>
> >> clang-tidy config files can be set in different places in the code to
> >> apply different checks in different places.
> >>
> >> Regards
> >>
> >> Jon
> >>
> >>
> >> --
> >> 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-proposal...@isocpp.org.
> >> To post to this group, send email to std-pr...@isocpp.org.
> >> To view this discussion on the web visit
> >>
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b9f1b29-cd23-4a12-9711-90d69de78669%40isocpp.org.
>
> >
> > --
> > 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-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > To view this discussion on the web visit
> >
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be2c389a-4624-43d3-8205-72c364e1c632%40isocpp.org.
>
>

--
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/9a3ddbb7-346e-434e-98bd-c2440bae630d%40isocpp.org.

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

<div dir=3D"ltr">Nobody is asking the committee to sort what is good or wha=
t is bad in C++. The whole idea is to allow the user to select that for him=
self what he considers valuable. goto was just an example, the idea was to =
have something more general. grep wouldn&#39;t help since it would select a=
ll instances without knowing which should be accepted and which shouldn&#39=
;t. Just use clang? Not everybody uses clang. Not everybody considers clang=
 good. The tools can&#39;t detect if a particular thing from the coding sta=
ndard is allowed in some piece of code or not. They only detect at project =
level. And that was my whole idea, give more granularity at code level. Whi=
ch would require the thing to be implemented in the compiler. Which probabl=
y would mean that it should be in the C++ standard.<br><br>On Wednesday, Ja=
nuary 25, 2017 at 1:37:50 PM UTC+2, Peter Koch Larsen wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">As Jonathan pointed out, this is a tooling is=
sue. I do not see any
<br>reason to let this be part of the C++ standard.
<br>Imagine the amount of work needed by the standard committee to sort
<br>out what is good and what is not a good part of C++. Do we really want
<br>the committee to focus on stuff like that - unlikely to be agreed upon
<br>before 2026 - instead of using its time on valuable stuff such as
<br>coroutines, modules and concepts?
<br>And frankly, what is the value of such a feature? Just use clang or
<br>other tools (for goto, grep comes to mind) to detect violations of a
<br>coding standard.
<br>
<br>/Peter
<br>
<br>On Wed, Jan 25, 2017 at 11:28 AM, =C2=A0&lt;<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"_llkQ1pXAgAJ" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.=
href=3D&#39;javascript:&#39;;return true;">sebastian.bu...@<wbr>gmail.com</=
a>&gt; wrote:
<br>&gt; I know tools like static analysis and lint work, but they are not =
universal.
<br>&gt; Of course, keeping it outside the compiler is neater because it se=
parates
<br>&gt; things, but what I was proposing was a universal lint of sorts. Mi=
crosoft
<br>&gt; has a linter, Clang has one, but the problem is learning each of t=
hese tools
<br>&gt; when switching projects and also that I am not sure that you can e=
nforce
<br>&gt; these hierarchies depending on modules like I am talking about. It=
 would
<br>&gt; make C++ more &#39;portable&#39; in a way.
<br>&gt;
<br>&gt; On Wednesday, January 25, 2017 at 9:56:27 AM UTC+2, Jonathan Coe w=
rote:
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; On 25 Jan 2017, at 07:21, <a>sebastian.bu...@gmail.com</a> wro=
te:
<br>&gt;&gt;
<br>&gt;&gt; Problem definition: Most projects have a document called &#39;=
Coding
<br>&gt;&gt; standards&#39; that represent rules for how the programmers sh=
ould use C++. Most
<br>&gt;&gt; of these documents basically define a subset of C++ that is en=
forced for
<br>&gt;&gt; that project. But the enforcement is usually done at the code =
review level
<br>&gt;&gt; where people point out when some C++ usage violates the rules.=
 Since these
<br>&gt;&gt; code reviews aren&#39;t always as thorough as they should be, =
or there aren&#39;t
<br>&gt;&gt; any code reviews due to other constraints, wouldn&#39;t it be =
nice if the
<br>&gt;&gt; compiler could enforce these rules and wouldn&#39;t let a piec=
e of code compile
<br>&gt;&gt; when the rules of the coding standard have been violated?
<br>&gt;&gt;
<br>&gt;&gt; Solution (proposed): Since C++ has object oriented support, I =
thought of
<br>&gt;&gt; something similar. You have a base class that represents the f=
ull set of the
<br>&gt;&gt; C++ standard. In order to enforce this class you don&#39;t hav=
e to do anything,
<br>&gt;&gt; so all C++ projects out there can choose to implement this enf=
orcement in
<br>&gt;&gt; their own time if they choose to. This base class can be deriv=
ed to add
<br>&gt;&gt; rules: for example you add the rule that goto is banned. Then,=
 you add
<br>&gt;&gt; something that would look like a preprocessor #ifdef - #endif =
block that
<br>&gt;&gt; means that for that part of code the subclass rules are enforc=
ed, thus any
<br>&gt;&gt; goto gets flagged and not allowed. These subclasses can be der=
ived further
<br>&gt;&gt; and more and more rules be enforced. With each derivation, mor=
e things from
<br>&gt;&gt; the C++ standard are removed. So you only substract with each =
derived class,
<br>&gt;&gt; you cannot add a new rule that goto is allowed after its super=
class banned
<br>&gt;&gt; it.
<br>&gt;&gt;
<br>&gt;&gt; But, at the code level, the subclassing is not enforced, you c=
an have a
<br>&gt;&gt; block that bans goto and inside have a subblock that allows it=
 temporarily.
<br>&gt;&gt; The basic idea isn&#39;t to have a million of these classes en=
forcing a billion
<br>&gt;&gt; rules but to be able to divide the codebase in things like hig=
h-level code
<br>&gt;&gt; and low-level code. In the high level portion you aren&#39;t a=
llowed to use
<br>&gt;&gt; things like pointer hacking, or naked pointers, while in the l=
ow level
<br>&gt;&gt; portion everything, or most things, are allowed. This way, if =
somebody is
<br>&gt;&gt; trying to modify some piece of code that he has never seen bef=
ore, he
<br>&gt;&gt; doesn&#39;t need to guess the way that code should be written =
in that module
<br>&gt;&gt; just by looking at the neighbouring code, but can actually jum=
p to the class
<br>&gt;&gt; that defines the rules and can read and follow them from there=
.. And if he
<br>&gt;&gt; doesn&#39;t follow them he can&#39;t compile. If he chooses to=
 create a subblock
<br>&gt;&gt; where he allows himself to do what he pleases, that is somethi=
ng that can be
<br>&gt;&gt; seen easier in the repository. Since creating new rules is bas=
ically
<br>&gt;&gt; creating new headers (or maybe a new type of file, special for=
 these rules),
<br>&gt;&gt; it&#39;s easier to control who creates the rules in a team so =
that not everybody
<br>&gt;&gt; can use and create whatever rule he wants whenever he wants (t=
hat would
<br>&gt;&gt; defeat the purpose of trying to enforce the coding standard).
<br>&gt;&gt;
<br>&gt;&gt; Since I&#39;ve heard that the module concept is coming to the =
next version of
<br>&gt;&gt; C++, maybe this would be a good idea to enforce the coding sta=
ndard at the
<br>&gt;&gt; module level.
<br>&gt;&gt;
<br>&gt;&gt; Right now I am only interested to see the reaction for this pr=
oposal as I
<br>&gt;&gt; haven&#39;t mapped out the nitty gritty details and see what c=
orners this design
<br>&gt;&gt; would force you into, so what do you think about the idea of f=
inding a way
<br>&gt;&gt; to enforce a subset of C++ at the compiler level?
<br>&gt;&gt;
<br>&gt;&gt; This feels more like a tooling issue than a language issue to =
me.
<br>&gt;&gt;
<br>&gt;&gt; I&#39;ve used clang-tidy
<br>&gt;&gt; <a href=3D"http://clang.llvm.org/extra/clang-tidy/" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fclang.llvm.org%2Fextra%2Fclang-tidy%2F\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNEuEWTbnZmQnIymRoRjJMSUXMRBYw&#39;;return true=
;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2F=
clang.llvm.org%2Fextra%2Fclang-tidy%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNEuEWTbnZmQnIymRoRjJMSUXMRBYw&#39;;return true;">http://clang.llvm.org/e=
xtra/<wbr>clang-tidy/</a> to enforce (parts of) in-house
<br>&gt;&gt; style guides with great success. Would that do what you need?
<br>&gt;&gt;
<br>&gt;&gt; clang-tidy config files can be set in different places in the =
code to
<br>&gt;&gt; apply different checks in different places.
<br>&gt;&gt;
<br>&gt;&gt; Regards
<br>&gt;&gt;
<br>&gt;&gt; Jon
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups
<br>&gt;&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an
<br>&gt;&gt; email to <a>std-proposal...@isocpp.org</a>.
<br>&gt;&gt; To post to this group, send email to <a>std-pr...@isocpp.org</=
a>.
<br>&gt;&gt; To view this discussion on the web visit
<br>&gt;&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-=
proposals/7b9f1b29-cd23-4a12-9711-90d69de78669%40isocpp.org" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7b9f1b29-cd23-4a12-9711-90d69de78669=
%40isocpp.org&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/7b9f1b29-cd23-4a12-9711-90d6=
9de78669%40isocpp.org&#39;;return true;">https://groups.google.com/a/<wbr>i=
socpp.org/d/msgid/std-<wbr>proposals/7b9f1b29-cd23-4a12-<wbr>9711-90d69de78=
669%40isocpp.org</a><wbr>.
<br>&gt;
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups
<br>&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an
<br>&gt; email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"_llkQ1pXAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"_llkQ1pXAgAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>&gt; To view this discussion on the web visit
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/be2c389a-4624-43d3-8205-72c364e1c632%40isocpp.org" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/be2c389a-4624-43d3-8205-72c364e1c632%40i=
socpp.org&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/be2c389a-4624-43d3-8205-72c364e1=
c632%40isocpp.org&#39;;return true;">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/be2c389a-4624-43d3-<wbr>8205-72c364e1c632%=
40isocpp.org</a><wbr>.
<br></blockquote></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/9a3ddbb7-346e-434e-98bd-c2440bae630d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9a3ddbb7-346e-434e-98bd-c2440bae630d=
%40isocpp.org</a>.<br />

------=_Part_55_1523911940.1485379685844--

------=_Part_54_567997480.1485379685844--

.

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

I think the only way to sort of achieve what you're asking in a way that
could be part of the standard and verified by compilers would be a form of
annotations.
One kind of "annotation" present in the language are the attributes which
gives the compiler more information about a piece of code, such as
[[noreturn]], [[fallthrough]], [[nodiscard]], [[maybe_unused]], etc.
Maybe you could propose a new set of attributes or even extended that idea
to be actual language annotations (as present in C#, Java).
However, there's a limit to what can be done using attributes according to
the current standard, you should check that before proposing anything.

On Wed, Jan 25, 2017 at 3:28 PM, <sebastian.bugiu.reloaded@gmail.com> wrote:

> Nobody is asking the committee to sort what is good or what is bad in C++.
> The whole idea is to allow the user to select that for himself what he
> considers valuable. goto was just an example, the idea was to have
> something more general. grep wouldn't help since it would select all
> instances without knowing which should be accepted and which shouldn't.
> Just use clang? Not everybody uses clang. Not everybody considers clang
> good. The tools can't detect if a particular thing from the coding standard
> is allowed in some piece of code or not. They only detect at project level.
> And that was my whole idea, give more granularity at code level. Which
> would require the thing to be implemented in the compiler. Which probably
> would mean that it should be in the C++ standard.
>
> On Wednesday, January 25, 2017 at 1:37:50 PM UTC+2, Peter Koch Larsen
> wrote:
>>
>> As Jonathan pointed out, this is a tooling issue. I do not see any
>> reason to let this be part of the C++ standard.
>> Imagine the amount of work needed by the standard committee to sort
>> out what is good and what is not a good part of C++. Do we really want
>> the committee to focus on stuff like that - unlikely to be agreed upon
>> before 2026 - instead of using its time on valuable stuff such as
>> coroutines, modules and concepts?
>> And frankly, what is the value of such a feature? Just use clang or
>> other tools (for goto, grep comes to mind) to detect violations of a
>> coding standard.
>>
>> /Peter
>>
>> On Wed, Jan 25, 2017 at 11:28 AM,  <sebastian.bu...@gmail.com> wrote:
>> > I know tools like static analysis and lint work, but they are not
>> universal.
>> > Of course, keeping it outside the compiler is neater because it
>> separates
>> > things, but what I was proposing was a universal lint of sorts.
>> Microsoft
>> > has a linter, Clang has one, but the problem is learning each of these
>> tools
>> > when switching projects and also that I am not sure that you can
>> enforce
>> > these hierarchies depending on modules like I am talking about. It
>> would
>> > make C++ more 'portable' in a way.
>> >
>> > On Wednesday, January 25, 2017 at 9:56:27 AM UTC+2, Jonathan Coe wrote:
>> >>
>> >>
>> >>
>> >> On 25 Jan 2017, at 07:21, sebastian.bu...@gmail.com wrote:
>> >>
>> >> Problem definition: Most projects have a document called 'Coding
>> >> standards' that represent rules for how the programmers should use
>> C++. Most
>> >> of these documents basically define a subset of C++ that is enforced
>> for
>> >> that project. But the enforcement is usually done at the code review
>> level
>> >> where people point out when some C++ usage violates the rules. Since
>> these
>> >> code reviews aren't always as thorough as they should be, or there
>> aren't
>> >> any code reviews due to other constraints, wouldn't it be nice if the
>> >> compiler could enforce these rules and wouldn't let a piece of code
>> compile
>> >> when the rules of the coding standard have been violated?
>> >>
>> >> Solution (proposed): Since C++ has object oriented support, I thought
>> of
>> >> something similar. You have a base class that represents the full set
>> of the
>> >> C++ standard. In order to enforce this class you don't have to do
>> anything,
>> >> so all C++ projects out there can choose to implement this enforcement
>> in
>> >> their own time if they choose to. This base class can be derived to
>> add
>> >> rules: for example you add the rule that goto is banned. Then, you add
>> >> something that would look like a preprocessor #ifdef - #endif block
>> that
>> >> means that for that part of code the subclass rules are enforced, thus
>> any
>> >> goto gets flagged and not allowed. These subclasses can be derived
>> further
>> >> and more and more rules be enforced. With each derivation, more things
>> from
>> >> the C++ standard are removed. So you only substract with each derived
>> class,
>> >> you cannot add a new rule that goto is allowed after its superclass
>> banned
>> >> it.
>> >>
>> >> But, at the code level, the subclassing is not enforced, you can have
>> a
>> >> block that bans goto and inside have a subblock that allows it
>> temporarily.
>> >> The basic idea isn't to have a million of these classes enforcing a
>> billion
>> >> rules but to be able to divide the codebase in things like high-level
>> code
>> >> and low-level code. In the high level portion you aren't allowed to
>> use
>> >> things like pointer hacking, or naked pointers, while in the low level
>> >> portion everything, or most things, are allowed. This way, if somebody
>> is
>> >> trying to modify some piece of code that he has never seen before, he
>> >> doesn't need to guess the way that code should be written in that
>> module
>> >> just by looking at the neighbouring code, but can actually jump to the
>> class
>> >> that defines the rules and can read and follow them from there. And if
>> he
>> >> doesn't follow them he can't compile. If he chooses to create a
>> subblock
>> >> where he allows himself to do what he pleases, that is something that
>> can be
>> >> seen easier in the repository. Since creating new rules is basically
>> >> creating new headers (or maybe a new type of file, special for these
>> rules),
>> >> it's easier to control who creates the rules in a team so that not
>> everybody
>> >> can use and create whatever rule he wants whenever he wants (that
>> would
>> >> defeat the purpose of trying to enforce the coding standard).
>> >>
>> >> Since I've heard that the module concept is coming to the next version
>> of
>> >> C++, maybe this would be a good idea to enforce the coding standard at
>> the
>> >> module level.
>> >>
>> >> Right now I am only interested to see the reaction for this proposal
>> as I
>> >> haven't mapped out the nitty gritty details and see what corners this
>> design
>> >> would force you into, so what do you think about the idea of finding a
>> way
>> >> to enforce a subset of C++ at the compiler level?
>> >>
>> >> This feels more like a tooling issue than a language issue to me.
>> >>
>> >> I've used clang-tidy
>> >> http://clang.llvm.org/extra/clang-tidy/ to enforce (parts of)
>> in-house
>> >> style guides with great success. Would that do what you need?
>> >>
>> >> clang-tidy config files can be set in different places in the code to
>> >> apply different checks in different places.
>> >>
>> >> Regards
>> >>
>> >> Jon
>> >>
>> >>
>> >> --
>> >> 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-proposal...@isocpp.org.
>> >> To post to this group, send email to std-pr...@isocpp.org.
>> >> To view this discussion on the web visit
>> >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals
>> /7b9f1b29-cd23-4a12-9711-90d69de78669%40isocpp.org.
>> >
>> > --
>> > 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-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>> > To view this discussion on the web visit
>> > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals
>> /be2c389a-4624-43d3-8205-72c364e1c632%40isocpp.org.
>>
> --
> 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/9a3ddbb7-346e-434e-
> 98bd-c2440bae630d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a3ddbb7-346e-434e-98bd-c2440bae630d%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CA%2BfGSbPe4N_uXJ9WaWqSJexS1Ssf5RJhohFsSaGCqfH-73vwrw%40mail.gmail.com.

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

<div dir=3D"ltr">I think the only way to sort of achieve what you&#39;re as=
king in a way that could be part of the standard and verified by compilers =
would be a form of annotations.<div>One kind of &quot;annotation&quot; pres=
ent in the language are the attributes which gives the compiler more inform=
ation about a piece of code, such as [[noreturn]], [[fallthrough]], [[nodis=
card]], [[maybe_unused]], etc.</div><div>Maybe you could propose a new set =
of attributes or even extended that idea to be actual language annotations =
(as present in C#, Java).</div><div>However, there&#39;s a limit to what ca=
n be done using attributes according to the current standard, you should ch=
eck that before proposing anything.<br></div></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Wed, Jan 25, 2017 at 3:28 PM,  <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:sebastian.bugiu.reloaded@gmail.com" target=
=3D"_blank">sebastian.bugiu.reloaded@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">Nobody is asking the committee=
 to sort what is good or what is bad in C++. The whole idea is to allow the=
 user to select that for himself what he considers valuable. goto was just =
an example, the idea was to have something more general. grep wouldn&#39;t =
help since it would select all instances without knowing which should be ac=
cepted and which shouldn&#39;t. Just use clang? Not everybody uses clang. N=
ot everybody considers clang good. The tools can&#39;t detect if a particul=
ar thing from the coding standard is allowed in some piece of code or not. =
They only detect at project level. And that was my whole idea, give more gr=
anularity at code level. Which would require the thing to be implemented in=
 the compiler. Which probably would mean that it should be in the C++ stand=
ard.<br><br>On Wednesday, January 25, 2017 at 1:37:50 PM UTC+2, Peter Koch =
Larsen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">As Jonathan pointed ou=
t, this is a tooling issue. I do not see any
<br>reason to let this be part of the C++ standard.
<br>Imagine the amount of work needed by the standard committee to sort
<br>out what is good and what is not a good part of C++. Do we really want
<br>the committee to focus on stuff like that - unlikely to be agreed upon
<br>before 2026 - instead of using its time on valuable stuff such as
<br>coroutines, modules and concepts?
<br>And frankly, what is the value of such a feature? Just use clang or
<br>other tools (for goto, grep comes to mind) to detect violations of a
<br>coding standard.
<br>
<br>/Peter
<br>
<br>On Wed, Jan 25, 2017 at 11:28 AM, =C2=A0&lt;<a rel=3D"nofollow">sebasti=
an.bu...@gmail.com</a>&gt; wrote:
<br>&gt; I know tools like static analysis and lint work, but they are not =
universal.
<br>&gt; Of course, keeping it outside the compiler is neater because it se=
parates
<br>&gt; things, but what I was proposing was a universal lint of sorts. Mi=
crosoft
<br>&gt; has a linter, Clang has one, but the problem is learning each of t=
hese tools
<br>&gt; when switching projects and also that I am not sure that you can e=
nforce
<br>&gt; these hierarchies depending on modules like I am talking about. It=
 would
<br>&gt; make C++ more &#39;portable&#39; in a way.
<br>&gt;
<br>&gt; On Wednesday, January 25, 2017 at 9:56:27 AM UTC+2, Jonathan Coe w=
rote:
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; On 25 Jan 2017, at 07:21, <a>sebastian.bu...@gmail.com</a> wro=
te:
<br>&gt;&gt;
<br>&gt;&gt; Problem definition: Most projects have a document called &#39;=
Coding
<br>&gt;&gt; standards&#39; that represent rules for how the programmers sh=
ould use C++. Most
<br>&gt;&gt; of these documents basically define a subset of C++ that is en=
forced for
<br>&gt;&gt; that project. But the enforcement is usually done at the code =
review level
<br>&gt;&gt; where people point out when some C++ usage violates the rules.=
 Since these
<br>&gt;&gt; code reviews aren&#39;t always as thorough as they should be, =
or there aren&#39;t
<br>&gt;&gt; any code reviews due to other constraints, wouldn&#39;t it be =
nice if the
<br>&gt;&gt; compiler could enforce these rules and wouldn&#39;t let a piec=
e of code compile
<br>&gt;&gt; when the rules of the coding standard have been violated?
<br>&gt;&gt;
<br>&gt;&gt; Solution (proposed): Since C++ has object oriented support, I =
thought of
<br>&gt;&gt; something similar. You have a base class that represents the f=
ull set of the
<br>&gt;&gt; C++ standard. In order to enforce this class you don&#39;t hav=
e to do anything,
<br>&gt;&gt; so all C++ projects out there can choose to implement this enf=
orcement in
<br>&gt;&gt; their own time if they choose to. This base class can be deriv=
ed to add
<br>&gt;&gt; rules: for example you add the rule that goto is banned. Then,=
 you add
<br>&gt;&gt; something that would look like a preprocessor #ifdef - #endif =
block that
<br>&gt;&gt; means that for that part of code the subclass rules are enforc=
ed, thus any
<br>&gt;&gt; goto gets flagged and not allowed. These subclasses can be der=
ived further
<br>&gt;&gt; and more and more rules be enforced. With each derivation, mor=
e things from
<br>&gt;&gt; the C++ standard are removed. So you only substract with each =
derived class,
<br>&gt;&gt; you cannot add a new rule that goto is allowed after its super=
class banned
<br>&gt;&gt; it.
<br>&gt;&gt;
<br>&gt;&gt; But, at the code level, the subclassing is not enforced, you c=
an have a
<br>&gt;&gt; block that bans goto and inside have a subblock that allows it=
 temporarily.
<br>&gt;&gt; The basic idea isn&#39;t to have a million of these classes en=
forcing a billion
<br>&gt;&gt; rules but to be able to divide the codebase in things like hig=
h-level code
<br>&gt;&gt; and low-level code. In the high level portion you aren&#39;t a=
llowed to use
<br>&gt;&gt; things like pointer hacking, or naked pointers, while in the l=
ow level
<br>&gt;&gt; portion everything, or most things, are allowed. This way, if =
somebody is
<br>&gt;&gt; trying to modify some piece of code that he has never seen bef=
ore, he
<br>&gt;&gt; doesn&#39;t need to guess the way that code should be written =
in that module
<br>&gt;&gt; just by looking at the neighbouring code, but can actually jum=
p to the class
<br>&gt;&gt; that defines the rules and can read and follow them from there=
.. And if he
<br>&gt;&gt; doesn&#39;t follow them he can&#39;t compile. If he chooses to=
 create a subblock
<br>&gt;&gt; where he allows himself to do what he pleases, that is somethi=
ng that can be
<br>&gt;&gt; seen easier in the repository. Since creating new rules is bas=
ically
<br>&gt;&gt; creating new headers (or maybe a new type of file, special for=
 these rules),
<br>&gt;&gt; it&#39;s easier to control who creates the rules in a team so =
that not everybody
<br>&gt;&gt; can use and create whatever rule he wants whenever he wants (t=
hat would
<br>&gt;&gt; defeat the purpose of trying to enforce the coding standard).
<br>&gt;&gt;
<br>&gt;&gt; Since I&#39;ve heard that the module concept is coming to the =
next version of
<br>&gt;&gt; C++, maybe this would be a good idea to enforce the coding sta=
ndard at the
<br>&gt;&gt; module level.
<br>&gt;&gt;
<br>&gt;&gt; Right now I am only interested to see the reaction for this pr=
oposal as I
<br>&gt;&gt; haven&#39;t mapped out the nitty gritty details and see what c=
orners this design
<br>&gt;&gt; would force you into, so what do you think about the idea of f=
inding a way
<br>&gt;&gt; to enforce a subset of C++ at the compiler level?
<br>&gt;&gt;
<br>&gt;&gt; This feels more like a tooling issue than a language issue to =
me.
<br>&gt;&gt;
<br>&gt;&gt; I&#39;ve used clang-tidy
<br>&gt;&gt; <a href=3D"http://clang.llvm.org/extra/clang-tidy/" rel=3D"nof=
ollow" target=3D"_blank">http://clang.llvm.org/extra/cl<wbr>ang-tidy/</a> t=
o enforce (parts of) in-house
<br>&gt;&gt; style guides with great success. Would that do what you need?
<br>&gt;&gt;
<br>&gt;&gt; clang-tidy config files can be set in different places in the =
code to
<br>&gt;&gt; apply different checks in different places.
<br>&gt;&gt;
<br>&gt;&gt; Regards
<br>&gt;&gt;
<br>&gt;&gt; Jon
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups
<br>&gt;&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an
<br>&gt;&gt; email to <a>std-proposal...@isocpp.org</a>.
<br>&gt;&gt; To post to this group, send email to <a>std-pr...@isocpp.org</=
a>.
<br>&gt;&gt; To view this discussion on the web visit
<br>&gt;&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-=
proposals/7b9f1b29-cd23-4a12-9711-90d69de78669%40isocpp.org" rel=3D"nofollo=
w" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/7b9f1b29-cd23-4a12-9711-<wbr>90d69de78669%40isocpp.org</a>=
..
<br>&gt;
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups
<br>&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an
<br>&gt; email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.
<br>&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...=
@isocpp.org</a>.
<br>&gt; To view this discussion on the web visit
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/be2c389a-4624-43d3-8205-72c364e1c632%40isocpp.org" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/be2c389a-4624-43d3-8205-<wbr>72c364e1c632%40isocpp.org</a>.
<br></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888888">

<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@<wbr>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/9a3ddbb7-346e-434e-98bd-c2440bae630d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9a3d=
dbb7-346e-434e-<wbr>98bd-c2440bae630d%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><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/CA%2BfGSbPe4N_uXJ9WaWqSJexS1Ssf5RJhoh=
FsSaGCqfH-73vwrw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPe4N_u=
XJ9WaWqSJexS1Ssf5RJhohFsSaGCqfH-73vwrw%40mail.gmail.com</a>.<br />

--001a114c877c1f9c6c0546f29d55--

.

--94eb2c192a048f076b0546f2f1b8
Content-Type: text/plain; charset=UTF-8

If you think this would be a cool feature to standardize, then please focus
on making an actual implementation inside an existing compiler. It is a
very bad idea to try and standardize something that doesn't exist and has
had no user experience. There is a large design space to consider here and
arguing over the details won't be very fruitful when all we have to work
with is our imagination.

--
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/CADbh%2BeS0svkYEzQKW7Sb4q8KcnfzTZN%2B%3DkCsCmHe9QakR%2BsKsw%40mail.gmail.com.

--94eb2c192a048f076b0546f2f1b8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">If you think this would be a cool feature to standardize, =
then please focus on making an actual implementation inside an existing com=
piler. It is a very bad idea to try and standardize something that doesn&#3=
9;t exist and has had no user experience. There is a large design space to =
consider here and arguing over the details won&#39;t be very fruitful when =
all we have to work with is our imagination.</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/CADbh%2BeS0svkYEzQKW7Sb4q8KcnfzTZN%2B=
%3DkCsCmHe9QakR%2BsKsw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2Be=
S0svkYEzQKW7Sb4q8KcnfzTZN%2B%3DkCsCmHe9QakR%2BsKsw%40mail.gmail.com</a>.<br=
 />

--94eb2c192a048f076b0546f2f1b8--

.

------=_Part_47_673053334.1485394442698
Content-Type: multipart/alternative;
 boundary="----=_Part_48_163126165.1485394442698"

------=_Part_48_163126165.1485394442698
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, January 25, 2017 at 1:28:06 PM UTC-8,=20
sebastian.bu...@gmail.com wrote:
>
> The tools can't detect if a particular thing from the coding standard is=
=20
allowed in
> some piece of code or not. They only detect at project level.

This sounds like a tooling issue.

> Just use clang? Not everybody uses clang. Not everybody considers clang=
=20
good.

This sounds like a *clang-specific* tooling issue. If you can point to a=20
specific way in which clang-tidy is suboptimal for your use case, the clang=
=20
bugzilla is thataway -->. Or if it's just a generalized "I feel=20
uncomfortable about Clang monoculture and wish there were some other really=
=20
good toolsets out there," I suppose there's nothing stopping you from=20
implementing a "competitor" toolset today. (There's also some very=20
innovative static-analysis stuff coming out of MSVC lately, and PVS-Studio,=
=20
and surely other things I'm not personally aware of. You could try out=20
those tools for your use case and again, if you find specific shortcomings,=
=20
file bugs or feature requests.)  Anyway, you should try the existing tools=
=20
before asking for completely new things that may or may not be any better.

On Wednesday, January 25, 2017 at 1:37:50 PM UTC+2, Peter Koch Larsen wrote=
:
> Imagine the amount of work needed by the standard committee to sort
> out what is good and what is not a good part of C++.

Technically, they're doing that all the time; and if there *are* any "bad=
=20
parts" of C++, someone's failing at their job. /tongue-in-cheek
(If there were actually no reason to use goto, the standard would get rid=
=20
of it. Compare goto's situation to that of C++03 auto and auto_ptr, which=
=20
were undone in C++11 and C++17 respectively. Quality control *is* being=20
done.)

=E2=80=93Arthur

--=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/cd5ca87d-1f4a-4d78-a9b7-f4fafdabf5a2%40isocpp.or=
g.

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

<div dir=3D"ltr">On Wednesday, January 25, 2017 at 1:28:06 PM UTC-8, sebast=
ian.bu...@gmail.com wrote:<br>&gt;<div>&gt; The tools can&#39;t detect if a=
 particular thing from the coding standard is allowed in<br></div><div>&gt;=
 some piece of code or not. They only detect at project level.</div><div><b=
r></div><div>This sounds like a tooling issue.</div><div><br></div><div><di=
v>&gt; Just use clang? Not everybody uses clang. Not everybody considers cl=
ang good.</div><div><br></div><div>This sounds like a <i><b>clang-specific<=
/b></i> tooling issue. If you can point to a specific way in which clang-ti=
dy is suboptimal for your use case, the clang bugzilla is thataway --&gt;. =
Or if it&#39;s just a generalized &quot;I feel uncomfortable about Clang mo=
noculture and wish there were some other really good toolsets out there,&qu=
ot; I suppose there&#39;s nothing stopping you from implementing a &quot;co=
mpetitor&quot; toolset today. (There&#39;s also some very innovative static=
-analysis stuff coming out of MSVC lately, and PVS-Studio, and surely other=
 things I&#39;m not personally aware of. You could try out those tools for =
your use case and again, if you find specific shortcomings, file bugs or fe=
ature requests.) =C2=A0Anyway, you should try the existing tools before ask=
ing for completely new things that may or may not be any better.</div><div>=
<br></div></div><div>On Wednesday, January 25, 2017 at 1:37:50 PM UTC+2, Pe=
ter Koch Larsen wrote:<br>&gt; Imagine the amount of work needed by the sta=
ndard committee to sort<br>&gt; out what is good and what is not a good par=
t of C++.</div><div><br></div><div>Technically, they&#39;re doing that all =
the time; and if there <i>are</i> any &quot;bad parts&quot; of C++, someone=
&#39;s failing at their job. /tongue-in-cheek</div><div>(If there were actu=
ally no reason to use <font face=3D"courier new, monospace">goto</font>, th=
e standard would get rid of it. Compare <font face=3D"courier new, monospac=
e">goto</font>&#39;s situation to that of C++03 <font face=3D"courier new, =
monospace">auto</font> and <font face=3D"courier new, monospace">auto_ptr</=
font><font face=3D"arial, sans-serif">, which were undone in C++11 and C++1=
7 respectively. Quality control <i>is</i> being done.)</font></div><div><br=
></div><div>=E2=80=93Arthur</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/cd5ca87d-1f4a-4d78-a9b7-f4fafdabf5a2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cd5ca87d-1f4a-4d78-a9b7-f4fafdabf5a2=
%40isocpp.org</a>.<br />

------=_Part_48_163126165.1485394442698--

------=_Part_47_673053334.1485394442698--

.

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

To me it looks a lot like proposing another standard, that could or not be
adopted by several tools.
But maybe it's too early for that, or maybe some format (clang-format?) is
already a defacto-standard.
Any way, the C++ standard should probably focus exclusively on the language
that have semantic,
while providing precise information and extension points for tools reading
it (like annotations).

Jo=C3=ABl Lamotte


On 26 January 2017 at 02:34, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Wednesday, January 25, 2017 at 1:28:06 PM UTC-8,
> sebastian.bu...@gmail.com wrote:
> >
> > The tools can't detect if a particular thing from the coding standard i=
s
> allowed in
> > some piece of code or not. They only detect at project level.
>
> This sounds like a tooling issue.
>
> > Just use clang? Not everybody uses clang. Not everybody considers clang
> good.
>
> This sounds like a *clang-specific* tooling issue. If you can point to a
> specific way in which clang-tidy is suboptimal for your use case, the cla=
ng
> bugzilla is thataway -->. Or if it's just a generalized "I feel
> uncomfortable about Clang monoculture and wish there were some other real=
ly
> good toolsets out there," I suppose there's nothing stopping you from
> implementing a "competitor" toolset today. (There's also some very
> innovative static-analysis stuff coming out of MSVC lately, and PVS-Studi=
o,
> and surely other things I'm not personally aware of. You could try out
> those tools for your use case and again, if you find specific shortcoming=
s,
> file bugs or feature requests.)  Anyway, you should try the existing tool=
s
> before asking for completely new things that may or may not be any better=
..
>
> On Wednesday, January 25, 2017 at 1:37:50 PM UTC+2, Peter Koch Larsen
> wrote:
> > Imagine the amount of work needed by the standard committee to sort
> > out what is good and what is not a good part of C++.
>
> Technically, they're doing that all the time; and if there *are* any "bad
> parts" of C++, someone's failing at their job. /tongue-in-cheek
> (If there were actually no reason to use goto, the standard would get rid
> of it. Compare goto's situation to that of C++03 auto and auto_ptr, which
> were undone in C++11 and C++17 respectively. Quality control *is* being
> done.)
>
> =E2=80=93Arthur
>
> --
> 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/cd5ca87d-1f4a-4d78-
> a9b7-f4fafdabf5a2%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cd5ca87d-1f=
4a-4d78-a9b7-f4fafdabf5a2%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAOU91ONMLELPcsvKaGjTQkzHm-WDjTMGsyxBQVDNx910V%2=
BpP%3DQ%40mail.gmail.com.

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

<div dir=3D"ltr">To me it looks a lot like proposing another standard, that=
 could or not be adopted by several tools.<div>But maybe it&#39;s too early=
 for that, or maybe some format (clang-format?) is already a defacto-standa=
rd.</div><div>Any way, the C++ standard should probably focus exclusively o=
n the language that have semantic,</div><div>while providing precise inform=
ation and extension points for tools reading it (like annotations).</div><d=
iv><br></div><div>Jo=C3=ABl Lamotte</div><div><br></div></div><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">On 26 January 2017 at 02:34, A=
rthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"mailto:arthur.j.odwyer@g=
mail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Wed=
nesday, January 25, 2017 at 1:28:06 PM UTC-8, <a href=3D"mailto:sebastian.b=
u...@gmail.com" target=3D"_blank">sebastian.bu...@gmail.com</a> wrote:<br>&=
gt;<div>&gt; The tools can&#39;t detect if a particular thing from the codi=
ng standard is allowed in<br></div><div>&gt; some piece of code or not. The=
y only detect at project level.</div><div><br></div></span><div>This sounds=
 like a tooling issue.</div><div><br></div><div><span class=3D""><div>&gt; =
Just use clang? Not everybody uses clang. Not everybody considers clang goo=
d.</div><div><br></div></span><div>This sounds like a <i><b>clang-specific<=
/b></i> tooling issue. If you can point to a specific way in which clang-ti=
dy is suboptimal for your use case, the clang bugzilla is thataway --&gt;. =
Or if it&#39;s just a generalized &quot;I feel uncomfortable about Clang mo=
noculture and wish there were some other really good toolsets out there,&qu=
ot; I suppose there&#39;s nothing stopping you from implementing a &quot;co=
mpetitor&quot; toolset today. (There&#39;s also some very innovative static=
-analysis stuff coming out of MSVC lately, and PVS-Studio, and surely other=
 things I&#39;m not personally aware of. You could try out those tools for =
your use case and again, if you find specific shortcomings, file bugs or fe=
ature requests.) =C2=A0Anyway, you should try the existing tools before ask=
ing for completely new things that may or may not be any better.</div><div>=
<br></div></div><div><span class=3D"">On Wednesday, January 25, 2017 at 1:3=
7:50 PM UTC+2, Peter Koch Larsen wrote:<br></span><span class=3D"">&gt; Ima=
gine the amount of work needed by the standard committee to sort<br>&gt; ou=
t what is good and what is not a good part of C++.</span></div><div><br></d=
iv><div>Technically, they&#39;re doing that all the time; and if there <i>a=
re</i> any &quot;bad parts&quot; of C++, someone&#39;s failing at their job=
.. /tongue-in-cheek</div><div>(If there were actually no reason to use <font=
 face=3D"courier new, monospace">goto</font>, the standard would get rid of=
 it. Compare <font face=3D"courier new, monospace">goto</font>&#39;s situat=
ion to that of C++03 <font face=3D"courier new, monospace">auto</font> and =
<font face=3D"courier new, monospace">auto_ptr</font><font face=3D"arial, s=
ans-serif">, which were undone in C++11 and C++17 respectively. Quality con=
trol <i>is</i> being done.)</font></div><div><br></div><div>=E2=80=93Arthur=
</div></div><span class=3D"">

<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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cd5ca87d-1f4a-4d78-a9b7-f4fafdabf5a2%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cd5c=
a87d-1f4a-4d78-<wbr>a9b7-f4fafdabf5a2%40isocpp.org</a><wbr>.<br>
</blockquote></div><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/CAOU91ONMLELPcsvKaGjTQkzHm-WDjTMGsyxB=
QVDNx910V%2BpP%3DQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONMLELP=
csvKaGjTQkzHm-WDjTMGsyxBQVDNx910V%2BpP%3DQ%40mail.gmail.com</a>.<br />

--001a1146c22ef11582054718bebb--

.