Topic: Group Member Specifiers
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Thu, 19 Dec 2013 03:50:32 -0800 (PST)
Raw View
------=_Part_202_11151834.1387453832858
Content-Type: text/plain; charset=ISO-8859-1
Let us define the Member Specifiers collectively as the non-type-specifer
decl-specifiers, the access-specifiers, virt-specifiers and pure specifier
as well as the two function bodies =delete and =default - and remove from
that set those that can never apply to a member declaration.
Specifically the Member Specifiers are
member-specifier:
friend
typedef
constexpr
static
thread_local
mutable
inline
virtual
explicit
override
final
= 0
= delete
= default
public
private
protected
Let us then define a comma-separated unordered subset of these:
member-specifier-list:
member-specifier
member-specifier-list , member-specifier
Now consider the C++ grammar with access-specifier replaced with
member-specifier-list:
member-specification:
member-declaration member-specification_opt
member-specifier-list : member-specification_opt
The semantics are that each member-specifier in the member-specifier-list
is applied to each of the following member-declarations up until the next
member-specifier-list, exactly as if each member declaration had been
explicitly declared with that member-specifier.
Many times we want to specify a sequence of related member declarations
with one or more common member-specifier. Rather than repeat the specifier
in each member declaration of the group, a member-specifier-list allows us
to specify the member-specifiers once at the start of the group. This can
in some cases lead to a much cleaner and easier to read and maintain class
specifier, as it removes noisy repetition.
Open questions/thoughts:
- Should member-specifier-list be comma-separated or space-separated
- Should the access-specifiers orthogonally be allowed as decl-specifiers
(like in Java/C#).
- Is there a better way to terminate the group than up until the next
member-specifier-list
- Should items be added, renamed or removed from member-specifier
- Should we add something similar at namespace-scope for namespace members.
Feedback welcome and appreciated.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_202_11151834.1387453832858
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Let us define the Member Specifiers collectively as the no=
n-type-specifer decl-specifiers, the access-specifiers, virt-specifiers and=
pure specifier as well as the two function bodies =3Ddelete and =3Ddefault=
- and remove from that set those that can never apply to a member declarat=
ion.<div><br></div><div>Specifically the Member Specifiers are</div><div><b=
r></div><div> member-specifier:</div><div> =
friend</div><div> typedef</div><div>&nbs=
p; constexpr</div><div> sta=
tic<br></div><div> thread_local</div><div> =
mutable</div><div> inline<=
/div><div> virtual</div><div>  =
; explicit</div><div> override<br></div><=
div> final</div><div> =
=3D 0</div><div> =3D delete</div><div> &n=
bsp; =3D default</div><div> public=
</div><div> private</div><div> &nbs=
p; protected</div><div><br></div><div>Let us then define a comma-sep=
arated unordered subset of these:</div><div><br></div><div> me=
mber-specifier-list:</div><div> member-specifier=
</div><div> member-specifier-list , member-speci=
fier</div><div><br></div><div>Now consider the C++ grammar with access-spec=
ifier replaced with member-specifier-list:</div><div><br></div><div><div>&n=
bsp; member-specification:</div><div> mem=
ber-declaration member-specification_opt</div><div> &nb=
sp; member-specifier-list : member-specification_opt</div></div><div><br></=
div><div>The semantics are that each member-specifier in the member-specifi=
er-list is applied to each of the following member-declarations up until th=
e next member-specifier-list, exactly as if each member declaration had bee=
n explicitly declared with that member-specifier.</div><div><br></div><div>=
Many times we want to specify a sequence of related member declarations wit=
h one or more common member-specifier. Rather than repeat the specifi=
er in each member declaration of the group, a member-specifier-list allows =
us to specify the member-specifiers once at the start of the group. =
This can in some cases lead to a much cleaner and easier to read and mainta=
in class specifier, as it removes noisy repetition.</div><div><br></div><di=
v>Open questions/thoughts:</div><div>- Should member-specifier-list be comm=
a-separated or space-separated</div><div>- Should the access-specifiers ort=
hogonally be allowed as decl-specifiers (like in Java/C#).</div><div>- Is t=
here a better way to terminate the group than up until the next member-spec=
ifier-list</div><div>- Should items be added, renamed or removed from membe=
r-specifier</div><div>- Should we add something similar at namespace-scope =
for namespace members.</div><div><br></div><div>Feedback welcome and apprec=
iated.</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_202_11151834.1387453832858--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 19 Dec 2013 15:29:17 +0200
Raw View
On 19 December 2013 13:50, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> Let us define the Member Specifiers collectively as the non-type-specifer
> decl-specifiers, the access-specifiers, virt-specifiers and pure specifier
> as well as the two function bodies =delete and =default - and remove from
> that set those that can never apply to a member declaration.
> Let us then define a comma-separated unordered subset of these:
>
> member-specifier-list:
> member-specifier
> member-specifier-list , member-specifier
>
> Now consider the C++ grammar with access-specifier replaced with
> member-specifier-list:
Did you plan to show an example of what you're striving for here and
why? I don't
speak grammar. :) In other words, examples and motivation, please.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Thu, 19 Dec 2013 06:00:39 -0800 (PST)
Raw View
------=_Part_604_22939908.1387461639737
Content-Type: text/plain; charset=ISO-8859-1
A basic example is access specifiers. Consider public. In C++, you have
class X {
public:
/* All the things I want public */
private:
/* All the other things */
};
In Java or C#, you must affix every member with public, like
class X {
public void f();
public void g();
};
But in C++, they use a Java-style approach for virtual- you have to define
every individual function as virtual. He wants to be able to set blocks of
functions as virtual, the way you can now for access specifiers.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_604_22939908.1387461639737
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A basic example is access specifiers. Consider public. In =
C++, you have<div><br></div><div>class X {</div><div>public:</div><div>&nbs=
p; /* All the things I want public */</div><div>private:</div><div>&=
nbsp; /* All the other things */</div><div>};</div><div><br></div><d=
iv>In Java or C#, you must affix every member with public, like</div><div><=
br></div><div>class X {</div><div> public void f();</div><div>=
public void g();</div><div>};</div><div><br></div><div>But in=
C++, they use a Java-style approach for virtual- you have to define every =
individual function as virtual. He wants to be able to set blocks of functi=
ons as virtual, the way you can now for access specifiers.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_604_22939908.1387461639737--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Thu, 19 Dec 2013 06:03:15 -0800 (PST)
Raw View
------=_Part_643_12762096.1387461795365
Content-Type: text/plain; charset=ISO-8859-1
Sure, it's actually pretty simple:
Sure, it's actually pretty simple. So instead of:
class IXMLProcessor
{
public:
virtual void startDocument() = 0;
virtual void endDocument() = 0;
virtual void startElement(const QName *name) = 0;
virtual void endElement() = 0;
virtual void attribute(const QName *name, const String &text) = 0;
virtual void text(const String &text) = 0;
virtual void comment(const String &text) = 0;
virtual ~XMLStream() {}
};
class MyXMLProcessor
{
public:
virtual void startDocument() override;
virtual void endDocument() override;
virtual void startElement(const QName *name) override;
virtual void endElement() override;
virtual void attribute(const QName *name, const String &text) override;
virtual void text(const String &text) override;
virtual void comment(const String &text) override;
virtual ~XMLStream() {}
};
You could write:
class IXMLProcessor
{
public, virtual, =0:
void startDocument();
void endDocument();
void startElement(const QName *name);
void endElement();
void attribute(const QName *name, const String &text);
void text(const String &text);
void comment(const String &text);
public:
virtual ~XMLStream() {}
};
class MyXMLProcessor
{
public, virtual, override:
void startDocument();
void endDocument();
void startElement(const QName *name);
void endElement();
void attribute(const QName *name, const String &text);
void text(const String &text);
void comment(const String &text);
};
And instead of:
template<class T>
class numeric_limits
{
public:
static constexpr const bool is_specialized = false;
static constexpr T min() __ntl_nothrow;
static constexpr T max() __ntl_nothrow;
static constexpr T lowest() __ntl_nothrow;
static constexpr const int digits = 0;
static constexpr const int digits10 = 0;
static constexpr const bool is_signed = false;
static constexpr const bool is_integer = false;
static constexpr const bool is_exact = false;
static constexpr const int radix = 0;
static constexpr T epsilon() __ntl_nothrow;
static constexpr T round_error() __ntl_nothrow;
static constexpr const int min_exponent = 0;
static constexpr const int min_exponent10 = 0;
static constexpr const int max_exponent = 0;
static constexpr const int max_exponent10 = 0;
static constexpr const bool has_infinity = false;
static constexpr const bool has_quiet_NaN = false;
static constexpr const bool has_signaling_NaN = false;
static constexpr const float_denorm_style has_denorm = denorm_absent;
static constexpr const bool has_denorm_loss = false;
static constexpr T infinity() __ntl_nothrow;
static constexpr T quiet_NaN() __ntl_nothrow;
static constexpr T signaling_NaN() __ntl_nothrow;
static constexpr T denorm_min() __ntl_nothrow;
static constexpr const bool is_iec559 = false;
static constexpr const bool is_bounded = false;
static constexpr const bool is_modulo = false;
static constexpr const bool traps = false;
static constexpr const bool tinyness_before = false;
static constexpr const float_round_style round_style =
round_toward_zero;
}; //template class numeric_limits
You could write:
template<class T>
class numeric_limits
{
public, static, constexpr:
const bool is_specialized = false;
T min() __ntl_nothrow;// { return T(false); }
T max() __ntl_nothrow;// { return T(false); }
T lowest() __ntl_nothrow;// { return T(false); }
const int digits = 0;
const int digits10 = 0;
const bool is_signed = false;
const bool is_integer = false;
const bool is_exact = false;
const int radix = 0;
T epsilon() __ntl_nothrow;// { return T(false); }
T round_error() __ntl_nothrow;// { return T(false); }
const int min_exponent = 0;
const int min_exponent10 = 0;
const int max_exponent = 0;
const int max_exponent10 = 0;
const bool has_infinity = false;
const bool has_quiet_NaN = false;
const bool has_signaling_NaN = false;
const float_denorm_style has_denorm = denorm_absent;
const bool has_denorm_loss = false;
T infinity() __ntl_nothrow;// { return T(false); }
T quiet_NaN() __ntl_nothrow;// { return T(false); }
T signaling_NaN() __ntl_nothrow;// { return T(false); }
T denorm_min() __ntl_nothrow;// { return T(false); }
const bool is_iec559 = false;
const bool is_bounded = false;
const bool is_modulo = false;
const bool traps = false;
const bool tinyness_before = false;
const float_round_style round_style = round_toward_zero;
};
On Thursday, December 19, 2013 2:29:17 PM UTC+1, Ville Voutilainen wrote:
>
> On 19 December 2013 13:50, Andrew Tomazos <andrew...@gmail.com<javascript:>>
> wrote:
> > Let us define the Member Specifiers collectively as the
> non-type-specifer
> > decl-specifiers, the access-specifiers, virt-specifiers and pure
> specifier
> > as well as the two function bodies =delete and =default - and remove
> from
> > that set those that can never apply to a member declaration.
> > Let us then define a comma-separated unordered subset of these:
> >
> > member-specifier-list:
> > member-specifier
> > member-specifier-list , member-specifier
> >
> > Now consider the C++ grammar with access-specifier replaced with
> > member-specifier-list:
>
>
> Did you plan to show an example of what you're striving for here and
> why? I don't
> speak grammar. :) In other words, examples and motivation, please.
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_643_12762096.1387461795365
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sure, it's actually pretty simple:<div><br></div><div><div=
>Sure, it's actually pretty simple. So instead of:</div><div><br></di=
v></div><blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px=
;"><div><div><font face=3D"courier new, monospace">class IXMLProcessor</fon=
t></div></div><div><div><font face=3D"courier new, monospace">{</font></div=
></div><div><div><font face=3D"courier new, monospace">public:</font></div>=
</div><div><div><font face=3D"courier new, monospace"> virtual=
void startDocument() =3D 0;</font></div></div><div><div><font face=3D"cour=
ier new, monospace"> virtual void endDocument() =3D 0;</font><=
/div></div><div><div><font face=3D"courier new, monospace"> &nb=
sp;</font></div></div><div><div><font face=3D"courier new, monospace"> =
; virtual void startElement(const QName *name) =3D 0;</font></div></=
div><div><div><font face=3D"courier new, monospace"> virtual v=
oid endElement() =3D 0;</font></div></div><div><div><font face=3D"courier n=
ew, monospace"> virtual void attribute(const QName *name, cons=
t String &text) =3D 0;</font></div></div><div><div><font face=3D"courie=
r new, monospace"> </font></div></div><div><div><font fac=
e=3D"courier new, monospace"> virtual void text(const String &=
amp;text) =3D 0;</font></div></div><div><div><font face=3D"courier new, mon=
ospace"> virtual void comment(const String &text) =3D 0;</=
font></div></div><div><div><font face=3D"courier new, monospace"><br></font=
></div></div><div><div><font face=3D"courier new, monospace"><span class=3D=
"Apple-tab-span" style=3D"white-space:pre"> </span>virtual ~XMLStream() {}<=
/font></div></div><div><div><font face=3D"courier new, monospace">};</font>=
</div></div><div><div><font face=3D"courier new, monospace"><br></font></di=
v></div><div><div><font face=3D"courier new, monospace">class MyXMLProcesso=
r</font></div></div><div><div><font face=3D"courier new, monospace">{</font=
></div></div><div><div><font face=3D"courier new, monospace">public:</font>=
</div></div><div><div><font face=3D"courier new, monospace"> v=
irtual void startDocument() override;</font></div></div><div><div><font fac=
e=3D"courier new, monospace"> virtual void endDocument() overr=
ide;</font></div></div><div><div><font face=3D"courier new, monospace">&nbs=
p; </font></div></div><div><div><font face=3D"courier new, mono=
space"> virtual void startElement(const QName *name) override;=
</font></div></div><div><div><font face=3D"courier new, monospace"> &=
nbsp; virtual void endElement() override;</font></div></div><div><div><font=
face=3D"courier new, monospace"> virtual void attribute(const=
QName *name, const String &text) override;</font></div></div><div><div=
><font face=3D"courier new, monospace"> </font></div></di=
v><div><div><font face=3D"courier new, monospace"> virtual voi=
d text(const String &text) override;</font></div></div><div><div><font =
face=3D"courier new, monospace"> virtual void comment(const St=
ring &text) override;</font></div></div><div><div><font face=3D"courier=
new, monospace"><br></font></div></div><div><div><font face=3D"courier new=
, monospace"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>virtual ~XMLStream() {}</font></div></div><div><div><font face=3D"courie=
r new, monospace">};</font></div></div></blockquote><div><div><br></div><di=
v>You could write:</div><div><br></div></div><blockquote style=3D"margin: 0=
0 0 40px; border: none; padding: 0px;"><div><div><font face=3D"courier new=
, monospace">class IXMLProcessor</font></div></div><div><div><font face=3D"=
courier new, monospace">{</font></div></div><div><div><font face=3D"courier=
new, monospace">public, virtual, =3D0:</font></div></div><div><div><font f=
ace=3D"courier new, monospace"> void startDocument();</font></=
div></div><div><div><font face=3D"courier new, monospace"> voi=
d endDocument();</font></div></div><div><div><font face=3D"courier new, mon=
ospace"> </font></div></div><div><div><font face=3D"couri=
er new, monospace"> void startElement(const QName *name);</fon=
t></div></div><div><div><font face=3D"courier new, monospace"> =
void endElement();</font></div></div><div><div><font face=3D"courier new, =
monospace"> void attribute(const QName *name, const String &am=
p;text);</font></div></div><div><div><font face=3D"courier new, monospace">=
</font></div></div><div><div><font face=3D"courier new, =
monospace"> void text(const String &text);</font></div></d=
iv><div><div><font face=3D"courier new, monospace"> void comme=
nt(const String &text);</font></div></div><div><div><font face=3D"couri=
er new, monospace"><br></font></div></div><div><div><font face=3D"courier n=
ew, monospace">public:</font></div></div><div><div><font face=3D"courier ne=
w, monospace"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </s=
pan>virtual ~XMLStream() {}</font></div></div><div><div><font face=3D"couri=
er new, monospace">};</font></div></div><div><div><font face=3D"courier new=
, monospace"><br></font></div></div><div><div><font face=3D"courier new, mo=
nospace">class MyXMLProcessor</font></div></div><div><div><font face=3D"cou=
rier new, monospace">{</font></div></div><div><div><font face=3D"courier ne=
w, monospace">public, virtual, override:</font></div></div><div><div><font =
face=3D"courier new, monospace"> void startDocument();</font><=
/div></div><div><div><font face=3D"courier new, monospace"> vo=
id endDocument();</font></div></div><div><div><font face=3D"courier new, mo=
nospace"> </font></div></div><div><div><font face=3D"cour=
ier new, monospace"> void startElement(const QName *name);</fo=
nt></div></div><div><div><font face=3D"courier new, monospace">  =
; void endElement();</font></div></div><div><div><font face=3D"courier new,=
monospace"> void attribute(const QName *name, const String &a=
mp;text);</font></div></div><div><div><font face=3D"courier new, monospace"=
> </font></div></div><div><div><font face=3D"courier new,=
monospace"> void text(const String &text);</font></div></=
div><div><div><font face=3D"courier new, monospace"> void comm=
ent(const String &text);</font></div></div><div><div><font face=3D"cour=
ier new, monospace">};</font></div></div></blockquote><div><div><br></div><=
div>And instead of:</div><div><br></div></div><blockquote style=3D"margin: =
0 0 0 40px; border: none; padding: 0px;"><div><div><font face=3D"courier ne=
w, monospace">template<class T></font></div></div><div><div><font fac=
e=3D"courier new, monospace">class numeric_limits</font></div></div><div><d=
iv><font face=3D"courier new, monospace">{</font></div></div><div><div><fon=
t face=3D"courier new, monospace"> public:</font></div></div><div><di=
v><font face=3D"courier new, monospace"> static constexpr cons=
t bool is_specialized =3D false;</font></div></div=
><div><div><font face=3D"courier new, monospace"> static const=
expr T min() =
__ntl_nothrow;</font></div></div><div><div><font face=
=3D"courier new, monospace"> static constexpr &n=
bsp; T max() =
__ntl_nothrow;</font></div></div><div><div><font face=3D"courier new, monos=
pace"> static constexpr T &n=
bsp; lowest() __ntl_nothrow;</font></div>=
</div><div><div><font face=3D"courier new, monospace"> static =
constexpr const int digits =
=3D 0;</font></div></div><div><div><font face=3D"courier new, monospa=
ce"> static constexpr const int digits10 &=
nbsp; =3D 0;</font></div></div><div><div><font face=3D"=
courier new, monospace"> static constexpr const bool &nb=
sp;is_signed =3D false;</font></div></div><div>=
<div><font face=3D"courier new, monospace"> static constexpr c=
onst bool is_integer =3D false;</fon=
t></div></div><div><div><font face=3D"courier new, monospace"> =
static constexpr const bool is_exact &nbs=
p; =3D false;</font></div></div><div><div><font face=3D"courier new, =
monospace"> static constexpr const int radix &nbs=
p; =3D 0;</font></div></div><div><div><f=
ont face=3D"courier new, monospace"> static constexpr &=
nbsp; T epsilon() __=
ntl_nothrow;</font></div></div><div><div><font face=3D"courier new, monospa=
ce"> static constexpr T &nbs=
p; round_error() __ntl_nothrow;</font></div></div><div><div><=
font face=3D"courier new, monospace"> static constexpr const &=
nbsp;int min_exponent =3D 0;</font></div></div><=
div><div><font face=3D"courier new, monospace"> static constex=
pr const int min_exponent10 =3D 0;</font></div></=
div><div><div><font face=3D"courier new, monospace"> static co=
nstexpr const int max_exponent =3D 0;</fon=
t></div></div><div><div><font face=3D"courier new, monospace"> =
static constexpr const int max_exponent10 =3D 0;=
</font></div></div><div><div><font face=3D"courier new, monospace"> &=
nbsp; static constexpr const bool has_infinity &n=
bsp;=3D false;</font></div></div><div><div><font face=3D"courier new, monos=
pace"> static constexpr const bool has_quiet_NaN &=
nbsp; =3D false;</font></div></div><div><div><font face=3D"courier n=
ew, monospace"> static constexpr const bool has_si=
gnaling_NaN =3D false;</font></div></div><div><div><font face=3D"courier ne=
w, monospace"> static constexpr const float_denorm_style=
has_denorm =3D denorm_absent;</font></div></div><div><div><fon=
t face=3D"courier new, monospace"> static constexpr const &nbs=
p;bool has_denorm_loss =3D false;</font></div></div><div><div>=
<font face=3D"courier new, monospace"> static constexpr =
T infinity() =
__ntl_nothrow;</font></div></div><div><div><font face=3D"courier new, monos=
pace"> static constexpr T &n=
bsp; quiet_NaN() __ntl_nothrow;</font></div></div><div=
><div><font face=3D"courier new, monospace"> static constexpr =
T signaling_NaN() __ntl_not=
hrow;</font></div></div><div><div><font face=3D"courier new, monospace">&nb=
sp; static constexpr T deno=
rm_min() __ntl_nothrow;</font></div></div><div><div><fo=
nt face=3D"courier new, monospace"> static constexpr const &nb=
sp;bool is_iec559 =3D false;</font></div>=
</div><div><div><font face=3D"courier new, monospace"> static =
constexpr const bool is_bounded =3D =
false;</font></div></div><div><div><font face=3D"courier new, monospace">&n=
bsp; static constexpr const bool is_modulo =
=3D false;</font></div></div><div><div><font face=3D"courier=
new, monospace"> static constexpr const bool trap=
s =3D false;</font></div></div><d=
iv><div><font face=3D"courier new, monospace"> static constexp=
r const bool tinyness_before =3D false;</font></div></di=
v><div><div><font face=3D"courier new, monospace"> static cons=
texpr const float_round_style round_style =3D round_toward_zero;</fon=
t></div></div><div><div><font face=3D"courier new, monospace">}; //template=
class numeric_limits</font></div></div></blockquote><div><div><br></div><d=
iv>You could write:</div><div><br></div></div><blockquote style=3D"margin: =
0 0 0 40px; border: none; padding: 0px;"><div><div><font face=3D"courier ne=
w, monospace">template<class T></font></div></div><div><div><font fac=
e=3D"courier new, monospace">class numeric_limits</font></div></div><div><d=
iv><font face=3D"courier new, monospace">{</font></div></div><div><div><fon=
t face=3D"courier new, monospace"> public, static, constexpr:</font><=
/div></div><div><div><font face=3D"courier new, monospace"> co=
nst bool is_specialized =3D false;</font></div></d=
iv><div><div><font face=3D"courier new, monospace"> &nb=
sp; T min() &=
nbsp; __ntl_nothrow;// { return T(false); }</font></div></div><div><div><fo=
nt face=3D"courier new, monospace">  =
;T max() __ntl_noth=
row;// { return T(false); }</font></div></div><div><div><font face=3D"couri=
er new, monospace"> T =
lowest() __ntl_nothrow;// { return T(fal=
se); }</font></div></div><div><div><font face=3D"courier new, monospace">&n=
bsp; const int digits  =
; =3D 0;</font></div></div><div><div><font face=3D"courier new, monos=
pace"> const int digits10 &n=
bsp; =3D 0;</font></div></div><div><div><font face=3D"courier new, mo=
nospace"> const bool is_signed  =
; =3D false;</font></div></div><div><div><font face=3D"courier new, =
monospace"> const bool is_integer &n=
bsp; =3D false;</font></div></div><div><div><font face=3D"courier new=
, monospace"> const bool is_exact &n=
bsp; =3D false;</font></div></div><div><div><font face=3D"cour=
ier new, monospace"> const int radix  =
; =3D 0;</font></div></div><div><div><font face=
=3D"courier new, monospace"> T &nbs=
p; epsilon() __ntl_nothrow;// { return T=
(false); }</font></div></div><div><div><font face=3D"courier new, monospace=
"> T round_error() &n=
bsp; __ntl_nothrow;// { return T(false); }</font></div></div><div><d=
iv><font face=3D"courier new, monospace"> const int &nbs=
p; min_exponent =3D 0;</font></div></div><div><div><fon=
t face=3D"courier new, monospace"> const int min_=
exponent10 =3D 0;</font></div></div><div><div><font face=3D"co=
urier new, monospace"> const int max_exponent &nb=
sp; =3D 0;</font></div></div><div><div><font face=3D"courier n=
ew, monospace"> const int max_exponent10 &=
nbsp;=3D 0;</font></div></div><div><div><font face=3D"courier new, monospac=
e"> const bool has_infinity =
=3D false;</font></div></div><div><div><font face=3D"courier new, monospace=
"> const bool has_quiet_NaN =3D fals=
e;</font></div></div><div><div><font face=3D"courier new, monospace"> =
const bool has_signaling_NaN =3D false;</font></div></d=
iv><div><div><font face=3D"courier new, monospace"> const &nbs=
p;float_denorm_style has_denorm =3D denorm_absent;</font></div>=
</div><div><div><font face=3D"courier new, monospace"> const &=
nbsp;bool has_denorm_loss =3D false;</font></div></div><div><d=
iv><font face=3D"courier new, monospace"> =
T infinity() __ntl_nothrow;=
// { return T(false); }</font></div></div><div><div><font face=3D"courier n=
ew, monospace"> T qui=
et_NaN() __ntl_nothrow;// { return T(false); }</font><=
/div></div><div><div><font face=3D"courier new, monospace"> &n=
bsp; T signaling_NaN() __ntl_nothr=
ow;// { return T(false); }</font></div></div><div><div><font face=3D"courie=
r new, monospace"> T =
denorm_min() __ntl_nothrow;// { return T(false); }</fon=
t></div></div><div><div><font face=3D"courier new, monospace"> =
const bool is_iec559 =3D false;</f=
ont></div></div><div><div><font face=3D"courier new, monospace"> &nbs=
p; const bool is_bounded =3D false;<=
/font></div></div><div><div><font face=3D"courier new, monospace"> &n=
bsp; const bool is_modulo =3D false=
;</font></div></div><div><div><font face=3D"courier new, monospace"> =
const bool traps &nbs=
p; =3D false;</font></div></div><div><div><font face=3D"courier new, monosp=
ace"> const bool tinyness_before =3D false;=
</font></div></div><div><div><font face=3D"courier new, monospace"> &=
nbsp; const float_round_style round_style =3D round_toward_zero;</fon=
t></div></div><div><div><font face=3D"courier new, monospace">};</font></di=
v></div></blockquote><div><br></div><div><br><div><br></div><div><br><br>On=
Thursday, December 19, 2013 2:29:17 PM UTC+1, Ville Voutilainen wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On 19 December 2013 13:50, Andrew =
Tomazos <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"X5bWlEVXtQ4J" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">andrew...@gmail.com</a>>=
; wrote:
<br>> Let us define the Member Specifiers collectively as the non-type-s=
pecifer
<br>> decl-specifiers, the access-specifiers, virt-specifiers and pure s=
pecifier
<br>> as well as the two function bodies =3Ddelete and =3Ddefault - and =
remove from
<br>> that set those that can never apply to a member declaration.
<br>> Let us then define a comma-separated unordered subset of these:
<br>>
<br>> member-specifier-list:
<br>> member-specifier
<br>> member-specifier-list , member-specifi=
er
<br>>
<br>> Now consider the C++ grammar with access-specifier replaced with
<br>> member-specifier-list:
<br>
<br>
<br>Did you plan to show an example of what you're striving for here and
<br>why? I don't
<br>speak grammar. :) In other words, examples and motivation, please.
<br></blockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_643_12762096.1387461795365--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 19 Dec 2013 16:09:41 +0200
Raw View
On 19 December 2013 16:03, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> Sure, it's actually pretty simple. So instead of:
Thanks for the example. I'm cautiously for this idea, but I'm not sure
the examples
are practically convincing. And I expect to hear that argument in a
stronger fashion
from other people.
We actually very briefly discussed making override/final member
specifiers, but that
idea didn't get anywhere. It was practically ignored, although I don't know why.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Thu, 19 Dec 2013 06:39:18 -0800 (PST)
Raw View
------=_Part_387_8851731.1387463958960
Content-Type: text/plain; charset=ISO-8859-1
override and final are context-sensitive keywords, so it would be a hassle
for the parser to deal with them in a decl-specifier-seq. That is my
understanding of why they are in the suffix of a function declarator. That
is just syntactic however and semantically they are essentially specifiers
that modify a member function declaration, so I include them in the initial
proposed list of possible member-specifiers. I think parsing a
member-specifier-list is pretty easy, but need to study it further. In the
worst case we could have a member-specifier-list introduced by an initial
access-specifier - but those are pretty minor details at this stage.
Also of interest from an existing practice pov is Qt signals and slots
which use this same type of group specifier syntax to define a group of
members that are all signals or all slots.
On Thursday, December 19, 2013 3:09:41 PM UTC+1, Ville Voutilainen wrote:
>
> On 19 December 2013 16:03, Andrew Tomazos <andrew...@gmail.com<javascript:>>
> wrote:
> > Sure, it's actually pretty simple. So instead of:
>
>
> Thanks for the example. I'm cautiously for this idea, but I'm not sure
> the examples
> are practically convincing. And I expect to hear that argument in a
> stronger fashion
> from other people.
>
> We actually very briefly discussed making override/final member
> specifiers, but that
> idea didn't get anywhere. It was practically ignored, although I don't
> know why.
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_387_8851731.1387463958960
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>override and final are context-sensitive keywords, so=
it would be a hassle for the parser to deal with them in a decl-specifier-=
seq. That is my understanding of why they are in the suffix of a func=
tion declarator. That is just syntactic however and semantically they=
are essentially specifiers that modify a member function declaration, so I=
include them in the initial proposed list of possible member-specifiers. &=
nbsp;I think parsing a member-specifier-list is pretty easy, but need to st=
udy it further. In the worst case we could have a member-specifier-li=
st introduced by an initial access-specifier - but those are pretty minor d=
etails at this stage.</div><div><br></div><div>Also of interest from an exi=
sting practice pov is Qt signals and slots which use this same type of grou=
p specifier syntax to define a group of members that are all signals or all=
slots.</div><div><br></div><div><div><div><div>On Thursday, December 19, 2=
013 3:09:41 PM UTC+1, Ville Voutilainen wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">On 19 December 2013 16:03, Andrew Tomazos <<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"9nBXMtMQ-acJ" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">andrew...@gmail.com</a>> wrote:
<br>> Sure, it's actually pretty simple. So instead of:
<br>
<br>
<br>Thanks for the example. I'm cautiously for this idea, but I'm not sure
<br>the examples
<br>are practically convincing. And I expect to hear that argument in a
<br>stronger fashion
<br>from other people.
<br>
<br>We actually very briefly discussed making override/final member
<br>specifiers, but that
<br>idea didn't get anywhere. It was practically ignored, although I don't =
know why.
<br></blockquote></div></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_387_8851731.1387463958960--
.
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Thu, 19 Dec 2013 16:20:29 +0100
Raw View
--f46d043c7eded90a0f04ede4b4a2
Content-Type: text/plain; charset=ISO-8859-1
This sounds a lot like how attributes can be used in D:
http://dlang.org/attribute.html
The behaviour in D is a little bit different than proposed. After
"override:", everything till the end of the class is override. A "public:"
or something later would not turn 'override' off. Apart from "attribute:",
there is also "attribute { ... }", which gives better control over to what
the attribute is applied.
Being able to do something like
static constexpr {
public:
...
private:
...
}
or
public:
static {
...
}
...
(in addition to what's originally proposed), would make it even more useful.
-Maurice-
2013/12/19 Andrew Tomazos <andrewtomazos@gmail.com>
> Let us define the Member Specifiers collectively as the non-type-specifer
> decl-specifiers, the access-specifiers, virt-specifiers and pure specifier
> as well as the two function bodies =delete and =default - and remove from
> that set those that can never apply to a member declaration.
>
> Specifically the Member Specifiers are
>
> member-specifier:
> friend
> typedef
> constexpr
> static
> thread_local
> mutable
> inline
> virtual
> explicit
> override
> final
> = 0
> = delete
> = default
> public
> private
> protected
>
> Let us then define a comma-separated unordered subset of these:
>
> member-specifier-list:
> member-specifier
> member-specifier-list , member-specifier
>
> Now consider the C++ grammar with access-specifier replaced with
> member-specifier-list:
>
> member-specification:
> member-declaration member-specification_opt
> member-specifier-list : member-specification_opt
>
> The semantics are that each member-specifier in the member-specifier-list
> is applied to each of the following member-declarations up until the next
> member-specifier-list, exactly as if each member declaration had been
> explicitly declared with that member-specifier.
>
> Many times we want to specify a sequence of related member declarations
> with one or more common member-specifier. Rather than repeat the specifier
> in each member declaration of the group, a member-specifier-list allows us
> to specify the member-specifiers once at the start of the group. This can
> in some cases lead to a much cleaner and easier to read and maintain class
> specifier, as it removes noisy repetition.
>
> Open questions/thoughts:
> - Should member-specifier-list be comma-separated or space-separated
> - Should the access-specifiers orthogonally be allowed as decl-specifiers
> (like in Java/C#).
> - Is there a better way to terminate the group than up until the next
> member-specifier-list
> - Should items be added, renamed or removed from member-specifier
> - Should we add something similar at namespace-scope for namespace members.
>
> Feedback welcome and appreciated.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--f46d043c7eded90a0f04ede4b4a2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This sounds a lot like how attributes can be used in D: <a=
href=3D"http://dlang.org/attribute.html">http://dlang.org/attribute.html</=
a><br><br>The behaviour in D is a little bit different than proposed. After=
"override:", everything till the end of the class is override. A=
"public:" or something later would not turn 'override' o=
ff. Apart from "attribute:", there is also "attribute { ... =
}", which gives better control over to what the attribute is applied.<=
br>
<br>Being able to do something like<br><br>static constexpr {<br>=A0=A0=A0=
=A0 public:<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0 ... <br>=A0=A0=A0=A0 private:<br=
>=A0=A0=A0=A0=A0=A0=A0=A0=A0 ... <br>}<br><br>or<br><br>public:<br>=A0=A0 s=
tatic {<br>=A0=A0=A0=A0=A0 ...<br>=A0=A0 }<br>=A0=A0 ...<br><br>(in additio=
n to what's originally proposed), would make it even more useful.<br>
<br>-Maurice-<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gma=
il_quote">2013/12/19 Andrew Tomazos <span dir=3D"ltr"><<a href=3D"mailto=
:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>>=
</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Let us define the Member Sp=
ecifiers collectively as the non-type-specifer decl-specifiers, the access-=
specifiers, virt-specifiers and pure specifier as well as the two function =
bodies =3Ddelete and =3Ddefault - and remove from that set those that can n=
ever apply to a member declaration.<div>
<br></div><div>Specifically the Member Specifiers are</div><div><br></div><=
div>=A0 =A0 member-specifier:</div><div>=A0 =A0 =A0 =A0 friend</div><div>=
=A0 =A0 =A0 =A0 typedef</div><div>=A0 =A0 =A0 =A0 constexpr</div><div>=A0 =
=A0 =A0 =A0 static<br></div><div>=A0 =A0 =A0 =A0 thread_local</div>
<div>=A0 =A0 =A0 =A0 mutable</div><div>=A0 =A0 =A0 =A0 inline</div><div>=A0=
=A0 =A0 =A0 virtual</div><div>=A0 =A0 =A0 =A0 explicit</div><div>=A0 =A0 =
=A0 =A0 override<br></div><div>=A0 =A0 =A0 =A0 final</div><div>=A0 =A0 =A0 =
=A0 =3D 0</div><div>=A0 =A0 =A0 =A0 =3D delete</div><div>=A0 =A0 =A0 =A0 =
=3D default</div>
<div>=A0 =A0 =A0 =A0 public</div><div>=A0 =A0 =A0 =A0 private</div><div>=A0=
=A0 =A0 =A0 protected</div><div><br></div><div>Let us then define a comma-=
separated unordered subset of these:</div><div><br></div><div>=A0 =A0 membe=
r-specifier-list:</div>
<div>
=A0 =A0 =A0 =A0 member-specifier</div><div>=A0 =A0 =A0 =A0 member-specifier=
-list , member-specifier</div><div><br></div><div>Now consider the C++ gram=
mar with access-specifier replaced with member-specifier-list:</div><div><b=
r></div><div>
<div>=A0 =A0 member-specification:</div><div>=A0 =A0 =A0 =A0 member-declara=
tion member-specification_opt</div><div>=A0 =A0 =A0 =A0 member-specifier-li=
st : member-specification_opt</div></div><div><br></div><div>The semantics =
are that each member-specifier in the member-specifier-list is applied to e=
ach of the following member-declarations up until the next member-specifier=
-list, exactly as if each member declaration had been explicitly declared w=
ith that member-specifier.</div>
<div><br></div><div>Many times we want to specify a sequence of related mem=
ber declarations with one or more common member-specifier. =A0Rather than r=
epeat the specifier in each member declaration of the group, a member-speci=
fier-list allows us to specify the member-specifiers once at the start of t=
he group. =A0 This can in some cases lead to a much cleaner and easier to r=
ead and maintain class specifier, as it removes noisy repetition.</div>
<div><br></div><div>Open questions/thoughts:</div><div>- Should member-spec=
ifier-list be comma-separated or space-separated</div><div>- Should the acc=
ess-specifiers orthogonally be allowed as decl-specifiers (like in Java/C#)=
..</div>
<div>- Is there a better way to terminate the group than up until the next =
member-specifier-list</div><div>- Should items be added, renamed or removed=
from member-specifier</div><div>- Should we add something similar at names=
pace-scope for namespace members.</div>
<div><br></div><div>Feedback welcome and appreciated.</div><span class=3D"H=
OEnZb"><font color=3D"#888888"><div><br></div></font></span></div><span cla=
ss=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d043c7eded90a0f04ede4b4a2--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 19 Dec 2013 08:59:57 -0800
Raw View
--nextPart2140023.52axPgWomA
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
On quinta-feira, 19 de dezembro de 2013 06:39:18, Andrew Tomazos wrote:
> Also of interest from an existing practice pov is Qt signals and slots
> which use this same type of group specifier syntax to define a group of
> members that are all signals or all slots.
Note that both syntaxes are possible:
class Foo : public QObject
{
Q_OBJECT
public slots: // note absence of comma as precedent
void slot1();
public:
Q_SLOT void slot2();
};
There's also a difference between singular and plural.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--nextPart2140023.52axPgWomA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQBSsyYNM/XwBW70U1gRAn39AJ9YhpjDckPBmj8bP7AFsGNHVb22hwCgrrdl
m1Q+KasTLQiGGyXO9cy6SDk=
=xDiA
-----END PGP SIGNATURE-----
--nextPart2140023.52axPgWomA--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Thu, 19 Dec 2013 19:03:12 +0100
Raw View
On Thu, Dec 19, 2013 at 03:50:32AM -0800, Andrew Tomazos wrote:
> Let us define the Member Specifiers collectively as the non-type-specifer
> decl-specifiers, the access-specifiers, virt-specifiers and pure specifier
> as well as the two function bodies =delete and =default - and remove from
> that set those that can never apply to a member declaration.
Should this allow member attributes, like [[noreturn]], to be specified as
well?
/MF
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: gmisocpp@gmail.com
Date: Thu, 19 Dec 2013 14:49:27 -0800 (PST)
Raw View
------=_Part_128_31215606.1387493367726
Content-Type: text/plain; charset=ISO-8859-1
Maybe it's time to get rid of = 0, and add abstract as a keyword. i.e.:
// Example 1:
class B {
void f() abstract; // use abstract to mean = 0;
};
class D : public B {
void f() override;
};
// Example 2:
class B abstract {
void f(); // abstract from class declaration.
};
class D : public B {
void f() override;
};
// Example 3:
class B {
abstract:
void f(); // abstract from label declaration:
};
class D : public B {
override:
void f();
};
On Friday, December 20, 2013 12:50:32 AM UTC+13, Andrew Tomazos wrote:
> Let us define the Member Specifiers collectively as the non-type-specifer
> decl-specifiers, the access-specifiers, virt-specifiers and pure specifier
> as well as the two function bodies =delete and =default - and remove from
> that set those that can never apply to a member declaration.
>
> Specifically the Member Specifiers are
>
> member-specifier:
> friend
> typedef
> constexpr
> static
> thread_local
> mutable
> inline
> virtual
> explicit
> override
> final
> = 0
> = delete
> = default
> public
> private
> protected
>
> Let us then define a comma-separated unordered subset of these:
>
> member-specifier-list:
> member-specifier
> member-specifier-list , member-specifier
>
> Now consider the C++ grammar with access-specifier replaced with
> member-specifier-list:
>
> member-specification:
> member-declaration member-specification_opt
> member-specifier-list : member-specification_opt
>
> The semantics are that each member-specifier in the member-specifier-list
> is applied to each of the following member-declarations up until the next
> member-specifier-list, exactly as if each member declaration had been
> explicitly declared with that member-specifier.
>
> Many times we want to specify a sequence of related member declarations
> with one or more common member-specifier. Rather than repeat the specifier
> in each member declaration of the group, a member-specifier-list allows us
> to specify the member-specifiers once at the start of the group. This can
> in some cases lead to a much cleaner and easier to read and maintain class
> specifier, as it removes noisy repetition.
>
> Open questions/thoughts:
> - Should member-specifier-list be comma-separated or space-separated
> - Should the access-specifiers orthogonally be allowed as decl-specifiers
> (like in Java/C#).
> - Is there a better way to terminate the group than up until the next
> member-specifier-list
> - Should items be added, renamed or removed from member-specifier
> - Should we add something similar at namespace-scope for namespace members.
>
> Feedback welcome and appreciated.
>
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_128_31215606.1387493367726
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Maybe it's time to get rid of =3D 0, and add abstract=
as a keyword. i.e.:</div><div><br></div><div>// Example 1:</div><div>class=
B {</div><div> void f() abstract; // use abstract to mean =
=3D 0;<br>};</div><div><br></div><div>class D : public B {</div><div>=
void f() override;</div><div>};</div><div><br></div><div>// Example =
2:</div><div><br></div><div>class B abstract {</div><div> void f(); /=
/ abstract from class declaration.</div><div>};</div><div><br></div><div>cl=
ass D : public B {</div><div>void f() override;</div><div>};</div><div><br>=
</div><div>// Example 3:</div><div><br></div><div>class B {</div><div>abstr=
act:</div><div>void f(); // abstract from label declaration:</div><div=
>};</div><div><br></div><div>class D : public B {</div><div>override:</div>=
<div>void f();</div><div>};<br></div><div><br>On Friday, December 20, 2013 =
12:50:32 AM UTC+13, Andrew Tomazos wrote:</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-co=
lor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"=
><div dir=3D"ltr">Let us define the Member Specifiers collectively as the n=
on-type-specifer decl-specifiers, the access-specifiers, virt-specifiers an=
d pure specifier as well as the two function bodies =3Ddelete and =3Ddefaul=
t - and remove from that set those that can never apply to a member declara=
tion.<div><br></div><div>Specifically the Member Specifiers are</div><div><=
br></div><div> member-specifier:</div><div>  =
; friend</div><div> typedef</div><div>&nb=
sp; constexpr</div><div> st=
atic<br></div><div> thread_local</div><div> =
; mutable</div><div> inline=
</div><div> virtual</div><div> &nbs=
p; explicit</div><div> override<br></div>=
<div> final</div><div>  =
; =3D 0</div><div> =3D delete</div><div> &=
nbsp; =3D default</div><div> publi=
c</div><div> private</div><div> &nb=
sp; protected</div><div><br></div><div>Let us then define a comma-se=
parated unordered subset of these:</div><div><br></div><div> m=
ember-specifier-list:</div><div> member-specifie=
r</div><div> member-specifier-list , member-spec=
ifier</div><div><br></div><div>Now consider the C++ grammar with access-spe=
cifier replaced with member-specifier-list:</div><div><br></div><div><div>&=
nbsp; member-specification:</div><div> me=
mber-declaration member-specification_opt</div><div> &n=
bsp; member-specifier-list : member-specification_opt</div></div><div><br><=
/div><div>The semantics are that each member-specifier in the member-specif=
ier-list is applied to each of the following member-declarations up until t=
he next member-specifier-list, exactly as if each member declaration had be=
en explicitly declared with that member-specifier.</div><div><br></div><div=
>Many times we want to specify a sequence of related member declarations wi=
th one or more common member-specifier. Rather than repeat the specif=
ier in each member declaration of the group, a member-specifier-list allows=
us to specify the member-specifiers once at the start of the group. =
This can in some cases lead to a much cleaner and easier to read and maint=
ain class specifier, as it removes noisy repetition.</div><div><br></div><d=
iv>Open questions/thoughts:</div><div>- Should member-specifier-list be com=
ma-separated or space-separated</div><div>- Should the access-specifiers or=
thogonally be allowed as decl-specifiers (like in Java/C#).</div><div>- Is =
there a better way to terminate the group than up until the next member-spe=
cifier-list</div><div>- Should items be added, renamed or removed from memb=
er-specifier</div><div>- Should we add something similar at namespace-scope=
for namespace members.</div><div><br></div><div>Feedback welcome and appre=
ciated.</div><div><br></div></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_128_31215606.1387493367726--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 20 Dec 2013 00:13:08 +0100
Raw View
--047d7b5d2ea4fc38f604edeb4d23
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Dec 19, 2013 at 11:49 PM, <gmisocpp@gmail.com> wrote:
> Maybe it's time to get rid of = 0, and add abstract as a keyword.
>
Both modifications would, if I understand correctly, not even be considered
by the committee if there is not strong rationals providing
example of important problems it would solve. Basically, I don't see how
such change would be considered.
The grouping proposal is interesting, I would have to check what kind of
impact it could have on my current code bases.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b5d2ea4fc38f604edeb4d23
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Dec 19, 2013 at 11:49 PM, <span dir=3D"ltr"><<a href=3D=
"mailto:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Maybe it's time to=
get rid of =3D 0, and add abstract as a keyword.=A0</div></div></blockquot=
e><div>
<br></div><div>Both modifications would, if I understand correctly, not eve=
n be considered by the committee if there is not strong rationals providing=
<br>example of important problems it would solve. Basically, I don't s=
ee how such change would be considered.</div>
<div><br></div><div><br></div><div><br><br>The grouping proposal is interes=
ting, I would have to check what kind of impact it could have on my current=
code bases.=A0</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b5d2ea4fc38f604edeb4d23--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 20 Dec 2013 01:59:47 +0200
Raw View
On 20 December 2013 01:13, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrote=
:
> On Thu, Dec 19, 2013 at 11:49 PM, <gmisocpp@gmail.com> wrote:
>> Maybe it's time to get rid of =3D 0, and add abstract as a keyword.
> Both modifications would, if I understand correctly, not even be consider=
ed
> by the committee if there is not strong rationals providing
> example of important problems it would solve. Basically, I don't see how
> such change would be considered.
We're not going to "get rid of =3D0". Discussing that is a waste of time.
Regarding abstract as a context-sensitive keyword, I think it should be
very easy to implement and has a certain consistency with override/final.
It would also be very easy to have an abstract function declaration that
is also a definition (although I don't know/remember why we don't support
void foo() =3D 0 {}). I wouldn't mind having such an abstract keyword,
but I can't really imagine a strong motivation for it that would likely
sway people to support it.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: gmisocpp@gmail.com
Date: Thu, 19 Dec 2013 17:55:25 -0800 (PST)
Raw View
------=_Part_241_9288519.1387504525958
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sorry I didn't mean "get rid of =3D 0" to suggest actually make it illegal =
or=20
deprecate it, it was just a bad turn of phrase.
I just meant introduce abstract since it is nicer IMHO. I like abstract as=
=20
a proposal on it's own, but I suggested abstract as much as an aid to this=
=20
proposal.
With the kind of fix it tools we are now seeing appear in clang etc. it=20
wouldn't be that hard I would think to create a conversion tool to replace=
=20
all =3D 0 with abstract either.
Another related syntactic change but going in the opposite direction might=
=20
be to allow public: etc. without a colon, for those who prefer to go to be=
=20
verbose and spell out each function in full. .e.g.:
class B {
public void f1();
private void f2();
};
It might be interesting to discuss the merits of verbose and non verbose=20
with regard to cut and pasting lines and how such syntactic option helps or=
=20
hinders that.
While I'm talking about ideas that probably won't get overwhelming=20
approval regarding these keywords, perhaps it's time to deprecate private=
=20
inheritance too, such that:
class X : D
generates a warning for the next 10 years, unless : private D is used=20
instead. Then eventually it could be deprecated and default to public=20
inheritance or left as is then as it still improves clarity even if the=20
default is not changed later.
On Friday, December 20, 2013 12:59:47 PM UTC+13, Ville Voutilainen wrote:
> On 20 December 2013 01:13, Klaim - Jo=EBl Lamotte <mjk...@gmail.com<javas=
cript:>>=20
> wrote:=20
> > On Thu, Dec 19, 2013 at 11:49 PM, <gmis...@gmail.com <javascript:>>=20
> wrote:=20
> >> Maybe it's time to get rid of =3D 0, and add abstract as a keyword.=20
> > Both modifications would, if I understand correctly, not even be=20
> considered=20
> > by the committee if there is not strong rationals providing=20
> > example of important problems it would solve. Basically, I don't see ho=
w=20
> > such change would be considered.=20
>
> We're not going to "get rid of =3D0". Discussing that is a waste of time.=
=20
> Regarding abstract as a context-sensitive keyword, I think it should be=
=20
> very easy to implement and has a certain consistency with override/final.=
=20
> It would also be very easy to have an abstract function declaration that=
=20
> is also a definition (although I don't know/remember why we don't support=
=20
> void foo() =3D 0 {}). I wouldn't mind having such an abstract keyword,=20
> but I can't really imagine a strong motivation for it that would likely=
=20
> sway people to support it.=20
>
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_241_9288519.1387504525958
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Sorry I didn't mean "get rid of =3D 0" =
;to suggest actually make it illegal or deprecate it, it was=
just a bad turn of phrase.</div><div><br></div><div>I just meant introduce=
abstract since it is nicer IMHO. I like abstract as a proposal o=
n it's own, but I suggested abstract as much as an aid to this proposa=
l.</div><div><br></div><div>With the kind of fix it tools we are now seeing=
appear in clang etc. it wouldn't be that hard I would think to create a co=
nversion tool to replace all =3D 0 with abstract either.</div><div><br></di=
v><div>Another related syntactic change but going in the opposite direction=
might be to allow public: etc. without a colon, for those who prefer to go=
to be verbose and spell out each function in full. .e.g.:</div><=
div><br></div><div>class B {</div><div> public void f1();</div><div>&=
nbsp; private void f2();</div><div>};</div><div><br></div><p>It might be in=
teresting to discuss the merits of verbose and non verbose with regard to&n=
bsp;cut and pasting lines and how such syntactic option helps or hinde=
rs that.</p><div><br></div><div>While I'm talking about ideas that probably=
won't get overwhelming approval regarding these keywords, perhap=
s it's time to deprecate private inheritance too, such that:=
</div><div><br></div><div>class X : D</div><div><br></div><div>generates a =
warning for the next 10 years, unless : private D is used instead. Then eve=
ntually it could be deprecated and default to public inheritance or left as=
is then as it still improves clarity even if the default is not chang=
ed later.</div><div><br></div><div><br>On Friday, December 20, 2013 12:59:4=
7 PM UTC+13, Ville Voutilainen wrote:</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">On =
20 December 2013 01:13, Klaim - Jo=EBl Lamotte <<a onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"R=
8g0AEZrG4oJ">mjk...@gmail.com</a>> wrote:
<br>> On Thu, Dec 19, 2013 at 11:49 PM, <<a onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"R8g0=
AEZrG4oJ">gmis...@gmail.com</a>> wrote:
<br>>> Maybe it's time to get rid of =3D 0, and add abstract as a key=
word.
<br>> Both modifications would, if I understand correctly, not even be c=
onsidered
<br>> by the committee if there is not strong rationals providing
<br>> example of important problems it would solve. Basically, I don't s=
ee how
<br>> such change would be considered.
<br>
<br>We're not going to "get rid of =3D0". Discussing that is a waste of tim=
e.
<br>Regarding abstract as a context-sensitive keyword, I think it should be
<br>very easy to implement and has a certain consistency with override/fina=
l.
<br>It would also be very easy to have an abstract function declaration tha=
t
<br>is also a definition (although I don't know/remember why we don't suppo=
rt
<br>void foo() =3D 0 {}). I wouldn't mind having such an abstract keyword,
<br>but I can't really imagine a strong motivation for it that would likely
<br>sway people to support it.
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_241_9288519.1387504525958--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 20 Dec 2013 10:11:01 +0800
Raw View
On 12/20/13 6:49 AM, gmisocpp@gmail.com wrote:
> Maybe it's time to get rid of = 0, and add abstract as a keyword. i.e.:
A few weeks ago I suggested to allow "! final" (or "not final") as a
synonym for "= 0", and also "! override" to assert that a new interface
is being introduced and avoid collision with a mix-in. The reception
wasn't so great.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 20 Dec 2013 09:51:32 +0200
Raw View
On 20 December 2013 03:55, <gmisocpp@gmail.com> wrote:
> Another related syntactic change but going in the opposite direction might
> be to allow public: etc. without a colon, for those who prefer to go to be
> verbose and spell out each function in full. .e.g.:
>
> class B {
> public void f1();
> private void f2();
> };
I fail to see why we'd do this, since it's a difference of one character.
> While I'm talking about ideas that probably won't get overwhelming approval
> regarding these keywords, perhaps it's time to deprecate private inheritance
> too, such that:
> class X : D
> generates a warning for the next 10 years, unless : private D is used
Perhaps not, because I again fail to find sufficient motivation.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: masse.nicolas@gmail.com
Date: Fri, 20 Dec 2013 04:42:22 -0800 (PST)
Raw View
------=_Part_615_21348316.1387543342980
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, December 20, 2013 2:55:25 AM UTC+1, gmis...@gmail.com wrote:
>
> Sorry I didn't mean "get rid of =3D 0" to suggest actually make it illega=
l=20
> or deprecate it, it was just a bad turn of phrase.
>
> I just meant introduce abstract since it is nicer IMHO. I like abstract a=
s=20
> a proposal on it's own, but I suggested abstract as much as an aid to thi=
s=20
> proposal.
>
> With the kind of fix it tools we are now seeing appear in clang etc. it=
=20
> wouldn't be that hard I would think to create a conversion tool to replac=
e=20
> all =3D 0 with abstract either.
>
Deprecating the use of " =3D 0 " in favor of an "abstract" keyword could be=
a=20
nice addition I think.
The motivation can be that it is more natural for a programmer to use a=20
keyword to mark methods as abstract than the " =3D 0" trick.
=20
>
> Another related syntactic change but going in the opposite direction migh=
t=20
> be to allow public: etc. without a colon, for those who prefer to go to b=
e=20
> verbose and spell out each function in full. .e.g.:
>
> class B {
> public void f1();
> private void f2();
> };
>
> It might be interesting to discuss the merits of verbose and non verbose=
=20
> with regard to cut and pasting lines and how such syntactic option helps =
or=20
> hinders that.
>
I tend to agree, but what about this:
class A {
public :
int method1();
int method2();
private int method3();
int method4();
private static:
void doSomething();
public doSomethingElse();
}
Is method3() public? private? ill-formed?
same question about method4.
Also, is doSomethingElse static?
> While I'm talking about ideas that probably won't get overwhelming=20
> approval regarding these keywords, perhaps it's time to deprecate private=
=20
> inheritance too, such that:
>
> class X : D
>
> generates a warning for the next 10 years, unless : private D is used=20
> instead. Then eventually it could be deprecated and default to public=20
> inheritance or left as is then as it still improves clarity even if the=
=20
> default is not changed later.
>
I don't really see the improvments here.
=20
>
>
> On Friday, December 20, 2013 12:59:47 PM UTC+13, Ville Voutilainen wrote:
>
>> On 20 December 2013 01:13, Klaim - Jo=EBl Lamotte <mjk...@gmail.com>=20
>> wrote:=20
>> > On Thu, Dec 19, 2013 at 11:49 PM, <gmis...@gmail.com> wrote:=20
>> >> Maybe it's time to get rid of =3D 0, and add abstract as a keyword.=
=20
>> > Both modifications would, if I understand correctly, not even be=20
>> considered=20
>> > by the committee if there is not strong rationals providing=20
>> > example of important problems it would solve. Basically, I don't see=
=20
>> how=20
>> > such change would be considered.=20
>>
>> We're not going to "get rid of =3D0". Discussing that is a waste of time=
..=20
>> Regarding abstract as a context-sensitive keyword, I think it should be=
=20
>> very easy to implement and has a certain consistency with override/final=
..=20
>> It would also be very easy to have an abstract function declaration that=
=20
>> is also a definition (although I don't know/remember why we don't suppor=
t=20
>> void foo() =3D 0 {}). I wouldn't mind having such an abstract keyword,=
=20
>> but I can't really imagine a strong motivation for it that would likely=
=20
>> sway people to support it.=20
>>
>
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_615_21348316.1387543342980
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, December 20, 2013 2:55:25 AM UTC+1, gmi=
s...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Sorry I didn't mean "get rid of =3D 0" to sugg=
est actually make it illegal or deprecate it, it was just a =
bad turn of phrase.</div><div><br></div><div>I just meant introduce abstrac=
t since it is nicer IMHO. I like abstract as a proposal on it's o=
wn, but I suggested abstract as much as an aid to this proposal.</div>=
<div><br></div><div>With the kind of fix it tools we are now seeing appear =
in clang etc. it wouldn't be that hard I would think to create a conversion=
tool to replace all =3D 0 with abstract either.</div></div></blockquote><d=
iv><br>Deprecating the use of " =3D 0 " in favor of an "abstract" keyword c=
ould be a nice addition I think.<br>The
motivation can be that it is more natural for a programmer to use a=20
keyword to mark methods as abstract than the " =3D 0" trick.<br> <br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br=
></div><div>Another related syntactic change but going in the opposite dire=
ction might be to allow public: etc. without a colon, for those who prefer =
to go to be verbose and spell out each function in full. .e.g.:</=
div><div><br></div><div>class B {</div><div> public void f1();</div><=
div> private void f2();</div><div>};</div><div><br></div><p>It might =
be interesting to discuss the merits of verbose and non verbose with regard=
to cut and pasting lines and how such syntactic option helps or =
hinders that.</p></div></blockquote><div>I tend to agree, but what about th=
is:<br><br>class A {<br>public :<br>int method1();<br>int method2();<br>pri=
vate int method3();<br>int method4();<br>private static:<br>void doSomethin=
g();<br>public doSomethingElse();<br>}<br><br>Is method3() public? private?=
ill-formed?<br>same question about method4.<br>Also, is doSomethingE=
lse static?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div><br></div><div>While I'm talking about ideas that probably=
won't get overwhelming approval regarding these keywords, perhap=
s it's time to deprecate private inheritance too, such that:=
</div><div><br></div><div>class X : D</div><div><br></div><div>generates a =
warning for the next 10 years, unless : private D is used instead. Then eve=
ntually it could be deprecated and default to public inheritance or left as=
is then as it still improves clarity even if the default is not chang=
ed later.</div></div></blockquote><div><br>I don't really see the improvmen=
ts here.<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><br></div><div><br>On Friday, December 20, 2013 12:59:47 PM=
UTC+13, Ville Voutilainen wrote:</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,=
204,204);border-left-width:1px;border-left-style:solid">On 20 December 2013=
01:13, Klaim - Jo=EBl Lamotte <<a>mjk...@gmail.com</a>> wrote:
<br>> On Thu, Dec 19, 2013 at 11:49 PM, <<a>gmis...@gmail.com</a>>=
wrote:
<br>>> Maybe it's time to get rid of =3D 0, and add abstract as a key=
word.
<br>> Both modifications would, if I understand correctly, not even be c=
onsidered
<br>> by the committee if there is not strong rationals providing
<br>> example of important problems it would solve. Basically, I don't s=
ee how
<br>> such change would be considered.
<br>
<br>We're not going to "get rid of =3D0". Discussing that is a waste of tim=
e.
<br>Regarding abstract as a context-sensitive keyword, I think it should be
<br>very easy to implement and has a certain consistency with override/fina=
l.
<br>It would also be very easy to have an abstract function declaration tha=
t
<br>is also a definition (although I don't know/remember why we don't suppo=
rt
<br>void foo() =3D 0 {}). I wouldn't mind having such an abstract keyword,
<br>but I can't really imagine a strong motivation for it that would likely
<br>sway people to support it.
<br></blockquote></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_615_21348316.1387543342980--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 20 Dec 2013 06:24:48 -0800 (PST)
Raw View
------=_Part_329_11222338.1387549488077
Content-Type: text/plain; charset=ISO-8859-1
On Friday, December 20, 2013 1:42:22 PM UTC+1, masse....@gmail.com wrote:
>
> I tend to agree, but what about this:
>
> class A {
> public :
> int method1();
> int method2();
> private int method3();
> int method4();
> private static:
> void doSomething();
> public doSomethingElse();
> }
>
> Is method3() public? private? ill-formed?
> same question about method4.
> Also, is doSomethingElse static?
>
(I will assume you meant to type "public void doSomethingElse()" and not
"public doSomethingElse()")
In my original proposal the access-specifiers are not allowed as
decl-specifiers as is the case now, so under it both method3 and
doSomethingElse are ill-formed syntax error.
However suppose we orthogonally added the access-specifiers as
decl-specifiers in addition to the proposal.
Then method3 is ill-formed as it is declared both public and private. It
would be like a declaration:
public private int method3();
doSomethingElse is also ill-formed as it is declared both private and
public. It would be like declaring:
private public static void doSomethingElse();
The implicit member-specifier-list at the start of a class is "private:"
and at the start of a struct is "public:".
In this world we would also need a way to declare an empty
member-specifier-list.
I'm currently thinking that adding the access-specifiers as decl-specifiers
is a bad idea.
An added benefit to not doing so, would free the access-specifier to always
introduce a member-specifier-list. This makes parsing a lot easier and
more efficient too, and allows us to definitely use space-separation.
So I amend the proposal as follows:
Remove access-specifier from member-specifier:
member-specifier:
friend
typedef
constexpr
static
thread_local
mutable
inline
virtual
explicit
override
final
= 0
= delete
= default
Define a space-separated unordered subset of these:
member-specifier-seq:
member-specifier
member-specifier-seq member-specifier
Now consider the C++ grammar with access-specifier having an optional
member-specifier-seq suffix (instead of being replaced):
member-specification:
member-declaration member-specification_opt
access-specifier member-specifier-seq_opt : member-specification_opt
^^^^^^^^^^^^^^^^^^^^^^^^
Now with a lookahead of one token the parser can determine which of the two
member-specification bodies it is in (as it can now). If it consumes an
access-specifier then it consumes member specifiers up until the next colon.
Semantically the member specifiers are then applied to each following
declaration up until the next access-specifier or end of the class.
From the users point of view it means that you simply have to place your
member specifiers (if any) after an access specifier. I think this is the
best way.
class C
{
public static constexpr: // OK
/* ... */
static public constexpr: // ERROR: public must go first
/* ... */
public void f(); // ERROR: public is not a decl-specifier (as is
the case now)
};
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_329_11222338.1387549488077
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 20, 2013 1:42:22 PM UTC+1, masse....@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div>I tend to agree, but what about this:<br><br>class A {<br>public :<b=
r>int method1();<br>int method2();<br>private int method3();<br>int method4=
();<br>private static:<br>void doSomething();<br>public doSomethingElse();<=
br>}<br><br>Is method3() public? private? ill-formed?<br>same questio=
n about method4.<br>Also, is doSomethingElse static?<br></div></div></block=
quote><div><br></div><div>(I will assume you meant to type "public void doS=
omethingElse()" and not "public doSomethingElse()")</div><div><br></div><di=
v>In my original proposal the access-specifiers are not allowed as decl-spe=
cifiers as is the case now, so under it both method3 and doSomethingElse ar=
e ill-formed syntax error.</div><div><br></div><div>However suppose we orth=
ogonally added the access-specifiers as decl-specifiers in addition to the =
proposal.</div><div><br></div><div>Then method3 is ill-formed as it is decl=
ared both public and private. It would be like a declaration:</div><d=
iv><br></div><div> public private int method3();</div><div><br=
></div><div>doSomethingElse is also ill-formed as it is declared both priva=
te and public. It would be like declaring:</div><div><br></div><div> =
private public static void doSomethingElse();</div><div><br></div><d=
iv>The implicit member-specifier-list at the start of a class is "private:"=
and at the start of a struct is "public:".</div><div><br></div><div>In thi=
s world we would also need a way to declare an empty member-specifier-list.=
</div><div><br></div><div>I'm currently thinking that adding the access-spe=
cifiers as decl-specifiers is a bad idea.</div><div><br></div><div>An added=
benefit to not doing so, would free the access-specifier to always introdu=
ce a member-specifier-list. This makes parsing a lot easier and more =
efficient too, and allows us to definitely use space-separation.</div><div>=
<br></div><div>So I amend the proposal as follows:</div><div><br></div><div=
>Remove access-specifier from member-specifier:</div><div><br></div><div><d=
iv><font face=3D"courier new, monospace"> member-specifier:</f=
ont></div><div><font face=3D"courier new, monospace"> &=
nbsp; friend</font></div><div><font face=3D"courier new, monospace"> =
typedef</font></div><div><font face=3D"courier new, mo=
nospace"> constexpr</font></div><div><font face=
=3D"courier new, monospace"> static<br></font></=
div><div><font face=3D"courier new, monospace"> =
thread_local</font></div><div><font face=3D"courier new, monospace"> =
mutable</font></div><div><font face=3D"courier new, mo=
nospace"> inline</font></div><div><font face=3D"=
courier new, monospace"> virtual</font></div><di=
v><font face=3D"courier new, monospace"> explici=
t</font></div><div><font face=3D"courier new, monospace"> &nbs=
p; override<br></font></div><div><font face=3D"courier new, monospac=
e"> final</font></div><div><font face=3D"courier=
new, monospace"> =3D 0</font></div><div><font f=
ace=3D"courier new, monospace"> =3D delete</font=
></div><div><font face=3D"courier new, monospace"> &nbs=
p; =3D default</font></div><div><br></div><div>Define a space-separated uno=
rdered subset of these:</div><div><br></div><div><font face=3D"courier new,=
monospace"> member-specifier-seq:</font></div><div><font face=
=3D"courier new, monospace"> member-specifier</f=
ont></div><div><font face=3D"courier new, monospace"> &=
nbsp; member-specifier-seq member-specifier</font></div><div><br></div><div=
>Now consider the C++ grammar with access-specifier having an optional memb=
er-specifier-seq suffix (instead of being replaced):</div><div><br></div><d=
iv><div><font face=3D"courier new, monospace"> member-specific=
ation:</font></div><div><font face=3D"courier new, monospace"> =
member-declaration member-specification_opt</font></div><div=
><font face=3D"courier new, monospace"> access-s=
pecifier member-specifier-seq_opt : member-specification_opt</font></div></=
div></div><div><font face=3D"courier new, monospace"> &=
nbsp; ^^^^^^^=
^^^^^^^^^^^^^^^^^</font></div><div><br></div><div>Now with a lookahead of o=
ne token the parser can determine which of the two member-specification bod=
ies it is in (as it can now). If it consumes an access-specifier then=
it consumes member specifiers up until the next colon.</div><div><br></div=
><div>Semantically the member specifiers are then applied to each following=
declaration up until the next access-specifier or end of the class.</div><=
div><br></div><div>From the users point of view it means that you simply ha=
ve to place your member specifiers (if any) after an access specifier. &nbs=
p;I think this is the best way.</div><div><br></div><div> &nbs=
p;class C</div><div> {</div><div> pub=
lic static constexpr: // OK</div><div> /* =
.... */</div><div><br></div><div> static public constexpr=
: // ERROR: public must go first</div><div> /* .=
... */</div><div><br></div><div> public void f();=
// ERROR: public is not a decl-specifier (as is the case now)</div><div>&n=
bsp; };</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_329_11222338.1387549488077--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 20 Dec 2013 17:48:55 +0200
Raw View
On 20 December 2013 14:42, <masse.nicolas@gmail.com> wrote:
> Deprecating the use of " = 0 " in favor of an "abstract" keyword could be a
> nice addition I think.
No thanks. The use of ' = 0' is not broken in any way, so there's no need
to deprecate it. I don't ever want to see an implementation diagnostic
suggesting that all my =0 uses are using a deprecated facility, and if I
do, I'll send angry letters to vendors of such implementations and the
committee.
> The motivation can be that it is more natural for a programmer to use a
> keyword to mark methods as abstract than the " = 0" trick.
The 'trick' has been in the language forever. Claiming that it's more 'natural'
to use a keyword invented after 4 standard revisions have shipped is
a bold claim.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 20 Dec 2013 17:21:20 +0100
Raw View
--001a11c2903c2210da04edf9aba7
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Dec 20, 2013 at 1:42 PM, <masse.nicolas@gmail.com> wrote:
> Deprecating the use of " = 0 " in favor of an "abstract" keyword could be
> a nice addition I think.
> The motivation can be that it is more natural for a programmer to use a
> keyword to mark methods as abstract than the " = 0" trick.
>
>
I think it would be much simpler to just
- add 'abstract' as an alias to =0 in our use case;
- say that the grouping feature don't accept =0 but do work with 'alias'
It's a bit like typedefs being possibly written as a using declaration, but
in one case corresponding to an additional feature (here template alias)
only the alternative "using" is allowed.
Deprecating =0 makes no sense to me, providing a clearer and more useful
alternative without deprecating seems far better.
In particular with huge codebases: it's hard to serach for =0, = 0,
=0, int k = 0 etc.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c2903c2210da04edf9aba7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Dec 20, 2013 at 1:42 PM, <span dir=3D"ltr"><<a href=3D"mailto:m=
asse.nicolas@gmail.com" target=3D"_blank">masse.nicolas@gmail.com</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>Deprecating the use of " =3D 0 &qu=
ot; in favor of an "abstract" keyword could be a nice addition I =
think.<br>
The
motivation can be that it is more natural for a programmer to use a=20
keyword to mark methods as abstract than the " =3D 0" trick.<br>=
=A0</div></blockquote></div><br>I think it would be much simpler to just=A0=
<br>=A0- add 'abstract' as an alias to =3D0 in our use case;</div><=
div class=3D"gmail_extra">
=A0- say that the grouping feature don't accept =3D0 but do work with &=
#39;alias'</div><div class=3D"gmail_extra"><br></div><div class=3D"gmai=
l_extra">It's a bit like typedefs being possibly written as a using dec=
laration, but in one case corresponding to an additional feature (here temp=
late alias)</div>
<div class=3D"gmail_extra">only the alternative "using" is allowe=
d.<br><br>Deprecating =3D0 makes no sense to me, providing a clearer and mo=
re useful alternative without deprecating seems far better.<br>In particula=
r with huge codebases: it's hard to serach for =3D0, =3D 0, =A0 =A0 =A0=
=3D0, int k =3D 0 etc.=A0</div>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2903c2210da04edf9aba7--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Fri, 20 Dec 2013 15:58:47 -0800 (PST)
Raw View
------=_Part_159_2933388.1387583927892
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, December 19, 2013 11:51:32 PM UTC-8, Ville Voutilainen wrote:
>
> On 20 December 2013 03:55, <gmis...@gmail.com <javascript:>> wrote:
> > Another related syntactic change but going in the opposite direction
> might
> > be to allow public: etc. without a colon, for those who prefer to go to
> be
> > verbose and spell out each function in full. .e.g.:
> >
> > class B {
> > public void f1();
> > private void f2();
> > };
>
> I fail to see why we'd do this, since it's a difference of one character.
>
It's less error prone. If you just prefix the method with public: then
that declaration _and all following ones_ are public until the next access
specifier. It's also an issue when you want to mix member functions of
differing privilege levels.
It's not a huge deal by any stretch, but it is certainly more than just
"one character" difference and nothing else.
Perhaps not, because I again fail to find sufficient motivation.
>
It confuses people. New users get tripped up by it often. Heck, I still
sometimes forget the public specifier and then get bitten by unexpected
compile errors.
> The motivation can be that it is more natural for a programmer to use a
> > keyword to mark methods as abstract than the " = 0" trick.
> The 'trick' has been in the language forever. Claiming that it's more
> 'natural'
> to use a keyword invented after 4 standard revisions have shipped is
> a bold claim.
It's hardly only just now being 'invented'. I even recall reading that
Bjarne had planned this change to a keyword in the early days but avoided
it to get things shipped and we've been stuck with =0 ever since.
Deprecating =0 is a bit much now of course, but offering 'abstract' as a
synonym is a more open topic I'd think.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_159_2933388.1387583927892
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, December 19, 2013 11:51:32 PM UTC-8, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 20 December=
2013 03:55, <<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"wjJp52svr70J" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">gmis...@gmail.c=
om</a>> wrote:
<br>> Another related syntactic change but going in the opposite directi=
on might
<br>> be to allow public: etc. without a colon, for those who prefer to =
go to be
<br>> verbose and spell out each function in full. .e.g.:
<br>>
<br>> class B {
<br>> public void f1();
<br>> private void f2();
<br>> };
<br>
<br>I fail to see why we'd do this, since it's a difference of one characte=
r.
<br></blockquote><div><br></div><div>It's less error prone. If you ju=
st prefix the method with public: then that declaration _and all following =
ones_ are public until the next access specifier. It's also an issue =
when you want to mix member functions of differing privilege levels.</div><=
div><br></div><div>It's not a huge deal by any stretch, but it is certainly=
more than just "one character" difference and nothing else.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">Perhaps not, because I a=
gain fail to find sufficient motivation.
<br></blockquote><div><br></div><div>It confuses people. New users ge=
t tripped up by it often. Heck, I still sometimes forget the public s=
pecifier and then get bitten by unexpected compile errors. </div><div=
><br></div><div><div class=3D"GIURNSTDOFB"><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-c=
olor: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">>=
; The motivation can be that it is more natural for a programmer to use a&n=
bsp;<br>> keyword to mark methods as abstract than the " =3D 0" trick.&n=
bsp;</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex;"><br>The 'trick' has been in t=
he language forever. Claiming that it's more 'natural' <br>to use a ke=
yword invented after 4 standard revisions have shipped is <br>a bold c=
laim. </blockquote><div><br></div><div>It's hardly only just now being=
'invented'. I even recall reading that Bjarne had planned this chang=
e to a keyword in the early days but avoided it to get things shipped and w=
e've been stuck with =3D0 ever since. </div><div><br></div><div>Deprec=
ating =3D0 is a bit much now of course, but offering 'abstract' as a synony=
m is a more open topic I'd think.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_159_2933388.1387583927892--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 21 Dec 2013 02:14:02 +0200
Raw View
On 21 December 2013 01:58, Sean Middleditch <sean.middleditch@gmail.com> wrote:
>> > class B {
>> > public void f1();
>> > private void f2();
>> > };
>> I fail to see why we'd do this, since it's a difference of one character.
> It's less error prone. If you just prefix the method with public: then that
Based on what evidence? If we add this form of an access specifier,
and then people end up making silly mistakes when they accidentally
use the legacy form, what's the conclusion of what's error-prone and what's
not?
> declaration _and all following ones_ are public until the next access
> specifier. It's also an issue when you want to mix member functions of
> differing privilege levels.
How common are such mixes?
> It's not a huge deal by any stretch, but it is certainly more than just "one
> character" difference and nothing else.
Agreed. It's much more than a "one character difference", it's a fair amount
of work at specifying it and implementing it, for questionable gain.
>> Perhaps not, because I again fail to find sufficient motivation.
> It confuses people. New users get tripped up by it often. Heck, I still
> sometimes forget the public specifier and then get bitten by unexpected
> compile errors.
I wouldn't trade such compiler errors for breaking an imperial boatload
of existing code.
>> > The motivation can be that it is more natural for a programmer to use a
>> > keyword to mark methods as abstract than the " = 0" trick.
>> The 'trick' has been in the language forever. Claiming that it's more
>> 'natural'
>> to use a keyword invented after 4 standard revisions have shipped is
>> a bold claim.
> It's hardly only just now being 'invented'. I even recall reading that
> Bjarne had planned this change to a keyword in the early days but avoided it
> to get things shipped and we've been stuck with =0 ever since.
That doesn't make changing from the current syntax to a new keyword
any more natural.
> Deprecating =0 is a bit much now of course, but offering 'abstract' as a
> synonym is a more open topic I'd think.
Well, it can certainly be discussed. Let's start with people finding a
good name for it.
I find it queasy that the first google search hits and wikipedia hits
describe an
"abstract method" as something that has no implementation. Shall we try "pure"
instead? A "pure function" has a fair amount of history that indicates
it may mean
something completely different than a pure virtual function.
Who do we help with this synonym, then?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: gmisocpp@gmail.com
Date: Sat, 21 Dec 2013 14:54:34 -0800 (PST)
Raw View
------=_Part_900_21387012.1387666474423
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, December 21, 2013 1:14:02 PM UTC+13, Ville Voutilainen wrote:
>
> On 21 December 2013 01:58, Sean Middleditch <sean.mid...@gmail.com<javascript:>>
> wrote:
> >> > class B {
> >> > public void f1();
> >> > private void f2();
> >> > };
> >> I fail to see why we'd do this, since it's a difference of one
> character.
> > It's less error prone. If you just prefix the method with public: then
> that
>
> Based on what evidence? If we add this form of an access specifier,
> and then people end up making silly mistakes when they accidentally
> use the legacy form, what's the conclusion of what's error-prone and
> what's
> not?
>
I've made mistakes with the current syntax and I'm sure I'll make
mistakes with any new syntax too. I'd say we're not talking about a "must
have" feature here as yet, but being pretty open to it as a "nice to have"
feature seems reasonable.
> > declaration _and all following ones_ are public until the next access
> > specifier. It's also an issue when you want to mix member functions of
> > differing privilege levels.
>
> How common are such mixes?
>
> > It's not a huge deal by any stretch, but it is certainly more than just
> "one
> > character" difference and nothing else.
>
> Agreed. It's much more than a "one character difference", it's a fair
> amount
> of work at specifying it and implementing it, for questionable gain.
>
I think it's more than a one character difference. I agree it's a fair
amount of work too. The discussion can't hurt though.
>
> >> Perhaps not, because I again fail to find sufficient motivation.
> > It confuses people. New users get tripped up by it often. Heck, I
> still
> > sometimes forget the public specifier and then get bitten by unexpected
> > compile errors.
>
> I wouldn't trade such compiler errors for breaking an imperial boatload
> of existing code.
>
I'm sure nobody will let a proposal through that will break "a boatload of
existing code" even if some initial ideas might accidentally imply that.
So breaking a boatload of code isn't realistic worry to my mind.
>
> >> > The motivation can be that it is more natural for a programmer to use
> a
> >> > keyword to mark methods as abstract than the " = 0" trick.
> >> The 'trick' has been in the language forever. Claiming that it's more
> >> 'natural'
> >> to use a keyword invented after 4 standard revisions have shipped is
> >> a bold claim.
> > It's hardly only just now being 'invented'. I even recall reading that
> > Bjarne had planned this change to a keyword in the early days but
> avoided it
> > to get things shipped and we've been stuck with =0 ever since.
>
> That doesn't make changing from the current syntax to a new keyword
> any more natural.
What's "natural" is obviously subjective. But I'd bet that preferring "=0"
to a real word is a minority view. I'd bet that "most people" would prefer
a word rather than something that looks like an assignment expression.
The issue is more that "most people" might not support a change to
introduce such a word like "abstract" here, even f they'd prefer it, if
that's all it was for, since we have something here already and that's
different argument. But I'm pretty sure the word vs =0 debate on it's own
would have the word choice win by a significant margin. There is already
some support here in this very thread for a word and other languages like
java have made that preference. I don't know of any languages other than
c++ that has chosen = 0 here and that syntax isn't very reusable.
> > Deprecating =0 is a bit much now of course, but offering 'abstract' as a
> > synonym is a more open topic I'd think.
>
> Well, it can certainly be discussed. Let's start with people finding a
> good name for it.
> I find it queasy that the first google search hits and wikipedia hits
> describe an
> "abstract method" as something that has no implementation. Shall we try
> "pure"
> instead? A "pure function" has a fair amount of history that indicates
> it may mean
> something completely different than a pure virtual function.
>
What do you find so "queasy" about "abstract"? In my admittedly brief
google attempt I found as much that would support "abstract" as anything
else.
>
> Who do we help with this synonym, then?
>
As part of a package of enhancements (also sold separately) I think these
things might add value. So "abstract" as a keyword being used at the class
level like other languages, and as a replacement for "=0" to tidy that
up, and in the list as suggested by the OP.
class vehicle abstract {
public void start(); // Implied abstract.
public void stop(); // Implied abstract.
};
class car : public vehicle { }
Quite what the keywords and syntactic changes are be it, final, pure etc.
is , but it'd be nice if they add up to something and fit together
collectively and get considered in these contexts as well as how they may
help or hinder when code is cut and pasted.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_900_21387012.1387666474423
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, December 21, 2013 1:14:02 PM UTC+13, =
Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;">On 21 December 2013 01=
:58, Sean Middleditch <<a onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"jyoFJKA4a9wJ">sean.mid...@=
gmail.com</a>> wrote:
<br>>> > class B {
<br>>> > public void f1();
<br>>> > private void f2();
<br>>> > };
<br>>> I fail to see why we'd do this, since it's a difference of one=
character.
<br>> It's less error prone. If you just prefix the method with pu=
blic: then that
<br>
<br>Based on what evidence? If we add this form of an access specifier,
<br>and then people end up making silly mistakes when they accidentally
<br>use the legacy form, what's the conclusion of what's error-prone and wh=
at's
<br>not?
<br></blockquote><div> </div><div>I've made mistakes with the cur=
rent syntax and I'm sure I'll make mistakes with any new syntax too.&n=
bsp;I'd say we're not talking about a "must have" feature&nb=
sp;here as yet, but being pretty open to it as a "nice to have" featur=
e seems reasonable.</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<br>> declaration _and all following ones_ are public until the next acc=
ess
<br>> specifier. It's also an issue when you want to mix member fu=
nctions of
<br>> differing privilege levels.
<br>
<br>How common are such mixes?
<br>
<br>> It's not a huge deal by any stretch, but it is certainly more than=
just "one
<br>> character" difference and nothing else.
<br>
<br>Agreed. It's much more than a "one character difference", it's a fair a=
mount
<br>of work at specifying it and implementing it, for questionable gain.
<br></blockquote><div><br></div><div>I think it's more than a one char=
acter difference. I agree it's a fair amount of work too. Th=
e discussion can't hurt though.</div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: =
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<br>>> Perhaps not, because I again fail to find sufficient motivatio=
n.
<br>> It confuses people. New users get tripped up by it often. &n=
bsp;Heck, I still
<br>> sometimes forget the public specifier and then get bitten by unexp=
ected
<br>> compile errors.
<br>
<br>I wouldn't trade such compiler errors for breaking an imperial boatload
<br>of existing code.
<br></blockquote><div> </div><div>I'm sure nobody will let a prop=
osal through that will break "a boatload of existing code" even if some ini=
tial ideas might accidentally imply that. So breaking a boatload of co=
de isn't realistic worry to my mind.</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-co=
lor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"=
>
<br>>> > The motivation can be that it is more natural for a progr=
ammer to use a
<br>>> > keyword to mark methods as abstract than the " =3D 0" tri=
ck.
<br>>> The 'trick' has been in the language forever. Claiming that it=
's more
<br>>> 'natural'
<br>>> to use a keyword invented after 4 standard revisions have ship=
ped is
<br>>> a bold claim.
<br>> It's hardly only just now being 'invented'. I even recall re=
ading that
<br>> Bjarne had planned this change to a keyword in the early days but =
avoided it
<br>> to get things shipped and we've been stuck with =3D0 ever since.
<br>
<br>That doesn't make changing from the current syntax to a new keyword
<br>any more natural.
</blockquote><div><br></div><div>What's "natural" is obviously subject=
ive. But I'd bet that preferring "=3D0" to a real word is a minority view. =
I'd bet that "most people" would prefer a word rather than something that l=
ooks like an assignment expression.</div><div><br></div><div>The issue=
is more that "most people" might not support a change to introduce&nb=
sp;such a word like "abstract" here, even f they'd prefer it=
, if that's all it was for, since we have something here already and t=
hat's different argument. But I'm pretty sure the word vs =3D0 debate on it=
's own would have the word choice win by a significant margin. There is alr=
eady some support here in this very thread for a word and other languages l=
ike java have made that preference. I don't know of any languages other tha=
n c++ that has chosen =3D 0 here and that syntax isn't very reusable.</div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;">
<br>> Deprecating =3D0 is a bit much now of course, but offering 'abstra=
ct' as a
<br>> synonym is a more open topic I'd think.
<br>
<br>Well, it can certainly be discussed. Let's start with people finding a
<br>good name for it.
<br>I find it queasy that the first google search hits and wikipedia hits
<br>describe an
<br>"abstract method" as something that has no implementation. Shall we try=
"pure"
<br>instead? A "pure function" has a fair amount of history that indicates
<br>it may mean
<br>something completely different than a pure virtual function.
<br></blockquote><div><br></div><div>What do you find so "queasy" about "ab=
stract"? In my admittedly brief google attempt I found as much th=
at would support "abstract" as anything else.</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-lef=
t-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: sol=
id;">
<br>Who do we help with this synonym, then?
<br></blockquote><div><br></div><div>As part of a package of enhancements (=
also sold separately) I think these things might add value. So "abstra=
ct" as a keyword being used at the class level like other languag=
es, and as a replacement for "=3D0" to tidy that up, and in the =
list as suggested by the OP.</div><div><br></div><div>class vehicle ab=
stract {</div><div>public void start(); // Implied abstract.</di=
v><div>public void stop(); // Implied abstract.</div><div>};</div><div>clas=
s car : public vehicle { }</div><div><br></div><div>Quite what the keywords=
and syntactic changes are be it, final, pure etc. is , but it'd be nice if=
they add up to something and fit together collectively and get considered =
in these contexts as well as how they may help or hinder when code is cut a=
nd pasted.</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_900_21387012.1387666474423--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 22 Dec 2013 01:06:16 +0200
Raw View
On 22 December 2013 00:54, <gmisocpp@gmail.com> wrote:
>> >> > public void f1();
>> >> > private void f2();
>> >> > };
>> >> I fail to see why we'd do this, since it's a difference of one
>> >> character.
>> > It's less error prone. If you just prefix the method with public: then
>> > that
>> Based on what evidence? If we add this form of an access specifier,
>> and then people end up making silly mistakes when they accidentally
>> use the legacy form, what's the conclusion of what's error-prone and
>> what's
>> not?
> I've made mistakes with the current syntax and I'm sure I'll make mistakes
> with any new syntax too. I'd say we're not talking about a "must have"
> feature here as yet, but being pretty open to it as a "nice to have" feature
> seems reasonable.
Yes? Still, I fail to see why we'd add this particular "nice to have" feature,
meaning I find the motivation for it insufficient. If people wish to provide
additional motivation, that's great, if they don't, I don't see why I'd support
such a "nice to have" feature, and I don't see why I wouldn't oppose it.
>> >> Perhaps not, because I again fail to find sufficient motivation.
>> > It confuses people. New users get tripped up by it often. Heck, I
>> > still
>> > sometimes forget the public specifier and then get bitten by unexpected
>> > compile errors.
>>
>> I wouldn't trade such compiler errors for breaking an imperial boatload
>> of existing code.
> I'm sure nobody will let a proposal through that will break "a boatload of
> existing code" even if some initial ideas might accidentally imply that. So
> breaking a boatload of code isn't realistic worry to my mind.
I don't think it's realistic to discuss changing the access default of classes
from private to public, if that's what people are really after here.
>> That doesn't make changing from the current syntax to a new keyword
>> any more natural.
> What's "natural" is obviously subjective. But I'd bet that preferring "=0"
> to a real word is a minority view. I'd bet that "most people" would prefer a
Given the consequences, I have doubts on that.
> The issue is more that "most people" might not support a change to introduce
> such a word like "abstract" here, even f they'd prefer it, if that's all it
> was for, since we have something here already and that's different argument.
Indeed.
> But I'm pretty sure the word vs =0 debate on it's own would have the word
> choice win by a significant margin. There is already some support here in
> this very thread for a word and other languages like java have made that
> preference. I don't know of any languages other than c++ that has chosen = 0
> here and that syntax isn't very reusable.
For java and other languages, see below.
>> Well, it can certainly be discussed. Let's start with people finding a
>> good name for it.
>> I find it queasy that the first google search hits and wikipedia hits
>> describe an
>> "abstract method" as something that has no implementation. Shall we try
>> "pure"
>> instead? A "pure function" has a fair amount of history that indicates
>> it may mean
>> something completely different than a pure virtual function.
> What do you find so "queasy" about "abstract"? In my admittedly brief google
> attempt I found as much that would support "abstract" as anything else.
I find queasy what I wrote above. An "abstract method" is described by wikipedia
as something that has no implementation, and that's how it is in at
least java, don't
remember the details of eg. c#. That's not the case for a pure virtual function
in C++, they can and often do have implementations, especially for the case
of pure virtual destructors.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Mon, 23 Dec 2013 09:46:05 -0500
Raw View
--089e0102f8320a975304ee34b037
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Dec 21, 2013 at 5:54 PM, <gmisocpp@gmail.com> wrote:
> What's "natural" is obviously subjective. But I'd bet that preferring "=0"
> to a real word is a minority view. I'd bet that "most people" would prefer
> a word rather than something that looks like an assignment expression.
>
>
Chances are that if this is changed at all the change would be the '0', not
the '='. Currently we have ' = delete' and ' = default'. In these two cases
the ' = ' can be read as 'defined as [deleted/defaulted]'. This is not
really the same case, as the 'pure' specifier is unrelated to the
definition of the function, but rather whether dynamic dispatch can find it
or whether it must be overridden by a derived type. While I don't
particularly like the idea of 'abstract' I could envision 'virtual void f()
= abstract;' as a possibility.
But to be honest I don't think that the current ' = 0' is really hurting
anyone. All newcomers to the language will find this described early in any
C++ OO tutorial and this is just something you learn. The '0' should not be
confused with anything else in any context.
David
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0102f8320a975304ee34b037
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Dec 21, 2013 at 5:54 PM, <span dir=3D"ltr"><<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>What's "natural"=A0is obviously subject=
ive. But I'd bet that preferring "=3D0" to a real word is a m=
inority view. I'd bet that "most people" would prefer a word =
rather than something that looks like an=A0assignment expression.</div>
<div><br></div></div></blockquote><div>=A0</div><div>Chances are that if th=
is is changed at all the change would be the '0', not the '=3D&=
#39;. Currently we have ' =3D delete' and ' =3D default'. I=
n these two cases the ' =3D ' can be read as 'defined as [delet=
ed/defaulted]'. This is not really the same case, as the 'pure'=
specifier is unrelated to the definition of the function, but rather wheth=
er dynamic dispatch can find it or whether it must be overridden by a deriv=
ed type. While I don't particularly like the idea of 'abstract'=
I could envision 'virtual void f() =3D abstract;' as a possibility=
..<br>
<br>But to be honest I don't think that the current ' =3D 0' is=
really hurting anyone. All newcomers to the language will find this descri=
bed early in any C++ OO tutorial and this is just something you learn. The =
'0' should not be confused with anything else in any context.<br>
<br>=A0 =A0 David<br><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0102f8320a975304ee34b037--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 23 Dec 2013 23:09:17 +0800
Raw View
On 12/23/13 10:46 PM, David Rodr=EDguez Ibeas wrote:
> On Sat, Dec 21, 2013 at 5:54 PM, <gmisocpp@gmail.com> wrote:
>
>> What's "natural" is obviously subjective. But I'd bet that preferring "=
=3D0"
>> to a real word is a minority view. I'd bet that "most people" would pref=
er
>> a word rather than something that looks like an assignment expression.
>>
>>
> Chances are that if this is changed at all the change would be the '0', n=
ot
> the '=3D'. Currently we have ' =3D delete' and ' =3D default'. In these t=
wo cases
> the ' =3D ' can be read as 'defined as [deleted/defaulted]'. This is not
> really the same case, as the 'pure' specifier is unrelated to the
> definition of the function, but rather whether dynamic dispatch can find =
it
> or whether it must be overridden by a derived type. While I don't
> particularly like the idea of 'abstract' I could envision 'virtual void f=
()
> =3D abstract;' as a possibility.
If the equals-sign is a liability, and doesn't reflect the newer meaning=20
related to definition, why keep it in "=3D abstract"? It's just confusing=
=20
that defining a pure virtual function is supported, but not with an=20
inline definition. (This furthermore makes the pure specifier=20
incompatible with deduced return type.)
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Mon, 23 Dec 2013 10:45:47 -0500
Raw View
--001a11c3b1b083af6004ee3585e8
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Dec 23, 2013 at 10:09 AM, David Krauss <potswa@gmail.com> wrote:
> If the equals-sign is a liability, and doesn't reflect the newer meaning
> related to definition, why keep it in "= abstract"? It's just confusing
> that defining a pure virtual function is supported, but not with an inline
> definition. (This furthermore makes the pure specifier incompatible with
> deduced return type.)
>
> I agree in the first account, on the first quick read '= delete' and '=
default' came to mind, and 'overrides' and 'final' were left aside. The
'abstract'-like specifier is more related to 'overrides' and 'final' than
it is to the former.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c3b1b083af6004ee3585e8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Dec 23, 2013 at 10:09 AM, David Krauss <span dir=3D"ltr"><<a href=3D=
"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span>=
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(3=
4,34,34)">If the equals-sign is a liability, and doesn't reflect the ne=
wer meaning related to definition, why keep it in "=3D abstract"?=
It's just confusing that defining a pure virtual function is supported=
, but not with an inline definition. (This furthermore makes the pure speci=
fier incompatible with deduced return type.)</span><br>
</div><div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote>=
<div>I agree in the first account, on the first quick read '=3D delete&=
#39; and '=3D default' came to mind, and 'overrides' and &#=
39;final' were left aside. The 'abstract'-like specifier is mor=
e related to 'overrides' and 'final' than it is to the form=
er.</div>
<div><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3b1b083af6004ee3585e8--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Mon, 23 Dec 2013 10:17:36 -0800
Raw View
--001a11334474e727cd04ee37a614
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
This whole thing is patently ridiculous. We have a syntax for declaring
things abstract. Creating a new syntax does not allow the programmer to
accomplish anything new, and does not make the code in question inherently
easier to read. I can see no reason to change it other than saying
"abstract" looks prettier, which is a terrible reason to make changes in
the core language at this point.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Mon, Dec 23, 2013 at 7:45 AM, David Rodr=EDguez Ibeas <dibeas@ieee.org>w=
rote:
> On Mon, Dec 23, 2013 at 10:09 AM, David Krauss <potswa@gmail.com> wrote:
>
>> If the equals-sign is a liability, and doesn't reflect the newer meaning
>> related to definition, why keep it in "=3D abstract"? It's just confusin=
g
>> that defining a pure virtual function is supported, but not with an inli=
ne
>> definition. (This furthermore makes the pure specifier incompatible with
>> deduced return type.)
>>
>> I agree in the first account, on the first quick read '=3D delete' and '=
=3D
> default' came to mind, and 'overrides' and 'final' were left aside. The
> 'abstract'-like specifier is more related to 'overrides' and 'final' than
> it is to the former.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11334474e727cd04ee37a614
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This whole thing is patently ridiculous. We have a syntax =
for declaring things abstract. Creating a new syntax does not allow the pro=
grammer to accomplish anything new, and does not make the code in question =
inherently easier to read. I can see no reason to change it other than sayi=
ng "abstract" looks prettier, which is a terrible reason to make =
changes in the core language at this point.</div>
<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 7:45 AM, David R=
odr=EDguez Ibeas <span dir=3D"ltr"><<a href=3D"mailto:dibeas@ieee.org" t=
arget=3D"_blank">dibeas@ieee.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
class=3D"im">On Mon, Dec 23, 2013 at 10:09 AM, David Krauss <span dir=3D"l=
tr"><<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.=
com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div><span style=3D"color:rgb(34,34,34)">If the equals-sig=
n is a liability, and doesn't reflect the newer meaning related to defi=
nition, why keep it in "=3D abstract"? It's just confusing th=
at defining a pure virtual function is supported, but not with an inline de=
finition. (This furthermore makes the pure specifier incompatible with dedu=
ced return type.)</span><br>
</div><div><div><br></div></div></blockquote></div><div>I agree in the firs=
t account, on the first quick read '=3D delete' and '=3D defaul=
t' came to mind, and 'overrides' and 'final' were left =
aside. The 'abstract'-like specifier is more related to 'overri=
des' and 'final' than it is to the former.</div>
<div><br></div></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11334474e727cd04ee37a614--
.
Author: gmisocpp@gmail.com
Date: Mon, 23 Dec 2013 13:22:17 -0800 (PST)
Raw View
------=_Part_2119_7052162.1387833737847
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, December 24, 2013 7:17:36 AM UTC+13, Billy O'Neal wrote:
>
> This whole thing is patently ridiculous. We have a syntax for declaring=
=20
> things abstract. Creating a new syntax does not allow the programmer to=
=20
> accomplish anything new, and does not make the code in question inherentl=
y=20
> easier to read. I can see no reason to change it other than saying=20
> "abstract" looks prettier, which is a terrible reason to make changes in=
=20
> the core language at this point.
>
> Billy O'Neal
>
You seem to be forgetting that the "abstract" suggestion I made is=20
in relation to the OP's thread about "Group Member Specifiers". i.e. The OP=
=20
was suggesting "public, =3D0:" as a syntax as "a group specififer", probabl=
y=20
to avoid a new word.
But pushing "=3D 0" to that position is ugly and not viable IMHO, where as=
=20
"public, abstract:" as a "group specifier" is more viable if the OP's idea=
=20
is going to get any traction, which is what I was trying to help with.
This is the topic of the thread after all, and that context that shouldn't=
=20
be forgotten here.
So *if* a word (I offered "abstract") instead of =3D 0 is going to be=20
accepted as a "group specifier", it's only right to float the idea as I=20
did, that it could be also be used in the same place as the "=3D 0" syntax=
=20
where it is currently used, because:
* "=3D0" that is pretty ugly and *isn't easily searchable*.
* "abstract" is a consistent meaning here if we enable it somewhere else.=
=20
Though will still have to search for both unless you using a conversion=20
too, but that might be viable now.
* *if* OP's proposal is to fly, something is needed, "=3D0" as a "group=20
specifier" isn't viable.
I don't support " =3D abstract", I prefer just "abstract" with no =3D, on t=
he=20
basis that it suggests assignment and doesn't match other languages like c#=
=20
or java. I think that's reasonable and also because c++ edges both ways=20
with it's specififers like static void f().
There isn't a definite balance either way to my mind. It similarly fits=20
with the other idea of allowing "public void f()" as well as "public: void=
=20
f();"
I prefer "abstract" over "pure" right now, because pure has other meanings=
=20
to me and those meanings have appeared in other recent proposals that may=
=20
well happen. and "abstract" could be used on the class too like some other=
=20
languages=20
I don't feel "=3D 0" will ever be deprecated either any time soon even if=
=20
this proposal was to fly, just to be triple clear about my opinion on that.
As I said before, none of this is strongly motivating to me, I'm just=20
trying to make the OP's original ideas more viable and be supportive until=
=20
it's time to conclude the evidence of all this and decide if it is viable=
=20
in the end.
Right now, I'm thinking this isn't viable as yet, but I'm open to seeing if=
=20
enough supportive ideas can change that situation..
=20
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Mon, Dec 23, 2013 at 7:45 AM, David Rodr=EDguez Ibeas <dib...@ieee.org=
<javascript:>
> > wrote:
>
>> On Mon, Dec 23, 2013 at 10:09 AM, David Krauss <pot...@gmail.com<javascr=
ipt:>
>> > wrote:
>>
>>> If the equals-sign is a liability, and doesn't reflect the newer meanin=
g=20
>>> related to definition, why keep it in "=3D abstract"? It's just confusi=
ng=20
>>> that defining a pure virtual function is supported, but not with an inl=
ine=20
>>> definition. (This furthermore makes the pure specifier incompatible wit=
h=20
>>> deduced return type.)
>>>
>>> I agree in the first account, on the first quick read '=3D delete' and =
'=3D=20
>> default' came to mind, and 'overrides' and 'final' were left aside. The=
=20
>> 'abstract'-like specifier is more related to 'overrides' and 'final' tha=
n=20
>> it is to the former.
>>
>> --=20
>> =20
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2119_7052162.1387833737847
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 24, 2013 7:17:36 AM UTC+13, B=
illy O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">This whole =
thing is patently ridiculous. We have a syntax for declaring things abstrac=
t. Creating a new syntax does not allow the programmer to accomplish anythi=
ng new, and does not make the code in question inherently easier to read. I=
can see no reason to change it other than saying "abstract" looks prettier=
, which is a terrible reason to make changes in the core language at this p=
oint.</div>
<div><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div></div><=
/div></div></blockquote><div><br></div><div>You seem to be forgetting =
that the "abstract" suggestion I made is in relation to the =
OP's thread about "Group Member Specifiers". i.e. The OP was suggesting "pu=
blic, =3D0:" as a syntax as "a group specififer", probably to avoid a new w=
ord.</div><div><br></div><div>But pushing "=3D 0" to that position is ugly =
and not viable IMHO, where as "public, abstract:" as a "group spe=
cifier" is more viable if the OP's idea is going to get any traction, which=
is what I was trying to help with.</div><div><br></div><div>This is the to=
pic of the thread after all, and that context that shouldn't be forgotten h=
ere.</div><div><br></div><div>So *if* a word (I offered "abs=
tract") instead of =3D 0 is going to be accepted as a "group specifier=
", it's only right to float the idea as I did, that it could be also be use=
d in the same place as the "=3D 0" syntax where it is currently used, =
because:</div><div><br></div><div>* "=3D0" that is pretty ugly and *is=
n't easily searchable*.</div><div>* "abstract" is a consistent meaning=
here if we enable it somewhere else. Though will still have to search for =
both unless you using a conversion too, but that might be viable now.</div>=
<div>* *if* OP's proposal is to fly, something is needed, "=3D0" as a&=
nbsp;"group specifier" isn't viable.</div><div><br></div><div>I don't =
support " =3D abstract", I prefer just "abstract" with no =3D, on the basis=
that it suggests assignment and doesn't match other languages like c# or j=
ava. I think that's reasonable and also because c++ edges both ways wi=
th it's specififers like static void f().</div><div>There isn't a definite =
balance either way to my mind. It similarly fits with the ot=
her idea of allowing "public void f()" as well as "public: void f();"<=
/div><div><br></div><div>I prefer "abstract" over "pure" right now, because=
pure has other meanings to me and those meanings have appeared in other re=
cent proposals that may well happen. and "abstract" could be used on t=
he class too like some other languages </div><div><br></div><div>I don't fe=
el "=3D 0" will ever be deprecated either any time soon even if this propos=
al was to fly, just to be triple clear about my opinion on that.</div><div>=
<br></div><div>As I said before, none of this is strongly motivating to me,=
I'm just trying to make the OP's original ideas more viable and be support=
ive until it's time to conclude the evidence of all this and decide if it i=
s viable in the end.</div><div><br></div><div>Right now, I'm thinking this&=
nbsp;isn't viable as yet, but I'm open to seeing if enough supportive ideas=
can change that situation..</div><div><br></div><div> </div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-l=
eft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bo=
rder-left-style: solid;"><div><div><div dir=3D"ltr"><div><a onmousedown=3D"=
this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fbitbucket.org%2FB=
illyONeal%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNEUaaIry0cea0l0vX6ztWgwQ7_4L=
g';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75htt=
ps%3A%2F%2Fbitbucket.org%2FBillyONeal%2F\46sa\75D\46sntz\0751\46usg\75AFQjC=
NEUaaIry0cea0l0vX6ztWgwQ7_4Lg';return true;" href=3D"https://bitbucket.org/=
BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></div><div=
><a onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2F=
stackoverflow.com%2Fusers%2F82320%2Fbilly-oneal\46sa\75D\46sntz\0751\46usg\=
75AFQjCNHY_gA133vyg0yY-U2PNMVA8cCSBg';return true;" onclick=3D"this.href=3D=
'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fusers%2F823=
20%2Fbilly-oneal\46sa\75D\46sntz\0751\46usg\75AFQjCNHY_gA133vyg0yY-U2PNMVA8=
cCSBg';return true;" href=3D"http://stackoverflow.com/users/82320/billy-one=
al" target=3D"_blank">http://stackoverflow.com/<wbr>users/82320/billy-oneal=
</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 7:45 AM, David R=
odr=EDguez Ibeas <span dir=3D"ltr"><<a onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';return true;" hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"hMjfqcroexgJ"=
>dib...@ieee.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: =
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>On Mon, Dec 23, 2013 =
at 10:09 AM, David Krauss <span dir=3D"ltr"><<a onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"hMjf=
qcroexgJ">pot...@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div><span style=3D"color: rgb(34, 34, 34);">I=
f the equals-sign is a liability, and doesn't reflect the newer meaning rel=
ated to definition, why keep it in "=3D abstract"? It's just confusing that=
defining a pure virtual function is supported, but not with an inline defi=
nition. (This furthermore makes the pure specifier incompatible with deduce=
d return type.)</span><br>
</div><div><div><br></div></div></blockquote></div><div>I agree in the firs=
t account, on the first quick read '=3D delete' and '=3D default' came to m=
ind, and 'overrides' and 'final' were left aside. The 'abstract'-like speci=
fier is more related to 'overrides' and 'final' than it is to the former.</=
div>
<div><br></div></div></div></div><div><div>
<p></p>
-- <br>
<br>
--- <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 onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"hMjfqcroexgJ">std-proposal...@<wbr>isocpp.=
org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;" href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"hMjfqcroexgJ">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a onmousedown=3D"this.href=3D'http://groups.google.com=
/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"this.href=3D'h=
ttp://groups.google.com/a/isocpp.org/group/std-proposals/';return true;" hr=
ef=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/" target=3D=
"_blank">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2119_7052162.1387833737847--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 24 Dec 2013 08:08:26 +0800
Raw View
On 12/24/13 2:17 AM, Billy O'Neal wrote:
> This whole thing is patently ridiculous. We have a syntax for declaring
> things abstract. Creating a new syntax does not allow the programmer to
> accomplish anything new, and does not make the code in question inherently
> easier to read.
As I just mentioned, an alternative to the pure-specifier would enable
definition at member-declaration scope (making code easier to read), and
restore compatibility with features that require such namely return type
deduction (I can't think of a case where this would be useful for a
virtual function, but it certainly qualifies as something new).
> I can see no reason to change it other than saying
> "abstract" looks prettier, which is a terrible reason to make changes in
> the core language at this point.
There is also my proposal for "not final" and "not override" which
improves regularity, as opposed to "= 0 final" which is valid grammar
but nonsense, and the current lack of a counterpoint to the override
specifier. But, that seems dead.
There are bigger fish to fry right now, but the potential gains are
nonzero. I don't see the downside; beginners will easily grasp the idea
of a keyword synonym to punctuation.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Tue, 31 Dec 2013 02:52:53 -0800 (PST)
Raw View
------=_Part_8032_6176807.1388487173762
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Thanks for your feedback. The proposal currently has the desirable=20
property (P) that the syntax and semantics of a specifier are consistent,=
=20
whether or not they are used in a member declaration or in group member=20
position. This applies also to pure-specifier.
While I think an argument could be made that a pure or abstract keyword=20
that also implied virtual would have been a better choice for the C++=20
pure-specifier than =3D0, and also that override and final should have been=
=20
in prefix position as full keywords as a decl-specifier - we can't really=
=20
go back in time and change it, and if we released a new standard that=20
specified that these things be changed, people would just ignore us.
With that given, I think it is more important to preserve P than to try and=
=20
"half-fix" the specifiers as part of this proposal. Any additional=20
"aliases" to the specifiers, or any new specifiers, should (a) come from a=
=20
different proposal; and (b) preserve P.
So:
class I
{
public:
virtual void f() =3D 0;
virtual void g() =3D 0;
virtual void h() =3D 0;
};
can alternatively be expressed:
class I
{
public virtual =3D 0:
void f();
void g();
void h();
};
Most agree, given we cannot change =3D 0, that this looks good to them.
On Monday, December 23, 2013 10:22:17 PM UTC+1, gmis...@gmail.com wrote:
>
>
>
> On Tuesday, December 24, 2013 7:17:36 AM UTC+13, Billy O'Neal wrote:
>>
>> This whole thing is patently ridiculous. We have a syntax for declaring=
=20
>> things abstract. Creating a new syntax does not allow the programmer to=
=20
>> accomplish anything new, and does not make the code in question inherent=
ly=20
>> easier to read. I can see no reason to change it other than saying=20
>> "abstract" looks prettier, which is a terrible reason to make changes in=
=20
>> the core language at this point.
>>
>> Billy O'Neal
>>
>
> You seem to be forgetting that the "abstract" suggestion I made is=20
> in relation to the OP's thread about "Group Member Specifiers". i.e. The =
OP=20
> was suggesting "public, =3D0:" as a syntax as "a group specififer", proba=
bly=20
> to avoid a new word.
>
> But pushing "=3D 0" to that position is ugly and not viable IMHO, where a=
s=20
> "public, abstract:" as a "group specifier" is more viable if the OP's ide=
a=20
> is going to get any traction, which is what I was trying to help with.
>
> This is the topic of the thread after all, and that context that shouldn'=
t=20
> be forgotten here.
>
> So *if* a word (I offered "abstract") instead of =3D 0 is going to be=20
> accepted as a "group specifier", it's only right to float the idea as I=
=20
> did, that it could be also be used in the same place as the "=3D 0" synta=
x=20
> where it is currently used, because:
>
> * "=3D0" that is pretty ugly and *isn't easily searchable*.
> * "abstract" is a consistent meaning here if we enable it somewhere else.=
=20
> Though will still have to search for both unless you using a conversion=
=20
> too, but that might be viable now.
> * *if* OP's proposal is to fly, something is needed, "=3D0" as a "group=
=20
> specifier" isn't viable.
>
> I don't support " =3D abstract", I prefer just "abstract" with no =3D, on=
the=20
> basis that it suggests assignment and doesn't match other languages like =
c#=20
> or java. I think that's reasonable and also because c++ edges both ways=
=20
> with it's specififers like static void f().
> There isn't a definite balance either way to my mind. It similarly fits=
=20
> with the other idea of allowing "public void f()" as well as "public: voi=
d=20
> f();"
>
> I prefer "abstract" over "pure" right now, because pure has other meaning=
s=20
> to me and those meanings have appeared in other recent proposals that may=
=20
> well happen. and "abstract" could be used on the class too like some othe=
r=20
> languages=20
>
> I don't feel "=3D 0" will ever be deprecated either any time soon even if=
=20
> this proposal was to fly, just to be triple clear about my opinion on tha=
t.
>
> As I said before, none of this is strongly motivating to me, I'm just=20
> trying to make the OP's original ideas more viable and be supportive unti=
l=20
> it's time to conclude the evidence of all this and decide if it is viable=
=20
> in the end.
>
> Right now, I'm thinking this isn't viable as yet, but I'm open to seeing=
=20
> if enough supportive ideas can change that situation..
>
> =20
>
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/users/82320/billy-oneal
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Mon, Dec 23, 2013 at 7:45 AM, David Rodr=EDguez Ibeas <dib...@ieee.or=
g>wrote:
>>
>>> On Mon, Dec 23, 2013 at 10:09 AM, David Krauss <pot...@gmail.com> wrote=
:
>>>
>>>> If the equals-sign is a liability, and doesn't reflect the newer=20
>>>> meaning related to definition, why keep it in "=3D abstract"? It's jus=
t=20
>>>> confusing that defining a pure virtual function is supported, but not =
with=20
>>>> an inline definition. (This furthermore makes the pure specifier=20
>>>> incompatible with deduced return type.)
>>>>
>>>> I agree in the first account, on the first quick read '=3D delete' and=
'=3D=20
>>> default' came to mind, and 'overrides' and 'final' were left aside. The=
=20
>>> 'abstract'-like specifier is more related to 'overrides' and 'final' th=
an=20
>>> it is to the former.
>>>
>>> --=20
>>> =20
>>> ---=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at=20
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_8032_6176807.1388487173762
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for your feedback. The proposal currently has=
the desirable property (P) that the syntax and semantics of a specifier ar=
e consistent, whether or not they are used in a member declaration or in gr=
oup member position. This applies also to pure-specifier.<div><br></d=
iv><div>While I think an argument could be made that a pure or abstract key=
word that also implied virtual would have been a better choice for the C++ =
pure-specifier than =3D0, and also that override and final should have been=
in prefix position as full keywords as a decl-specifier - we can't really =
go back in time and change it, and if we released a new standard that speci=
fied that these things be changed, people would just ignore us.<br><div><br=
></div><div>With that given, I think it is more important to preserve P tha=
n to try and "half-fix" the specifiers as part of this proposal. Any =
additional "aliases" to the specifiers, or any new specifiers, should (a) c=
ome from a different proposal; and (b) preserve P.</div><div><br></div><div=
>So:</div><div><br></div><div> class I</div><div> =
{</div><div> public:</div><div><div> &nbs=
p; virtual void f() =3D 0;</div></div><div><div><div> &=
nbsp; virtual void g() =3D 0;</div></div></div><div><div> &nbs=
p; virtual void h() =3D 0;</div></div><div> };</div><di=
v><br></div><div>can alternatively be expressed:</div><div><br></div><div>&=
nbsp; class I</div><div> {</div><div> publ=
ic virtual =3D 0:</div><div><div> void f();</div=
><div> void g();</div><div> =
void h();</div><div> };</div><div><br></div></div><div>=
Most agree, given we cannot change =3D 0, that this looks good to them.</di=
v><div><div><br>On Monday, December 23, 2013 10:22:17 PM UTC+1, gmis...@gma=
il.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><br>On Tuesday, December 24, 2013 7:17:36 AM UTC+13, Billy O'Neal wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid"><div dir=3D"ltr">This whole thing is patently ridiculous.=
We have a syntax for declaring things abstract. Creating a new syntax does=
not allow the programmer to accomplish anything new, and does not make the=
code in question inherently easier to read. I can see no reason to change =
it other than saying "abstract" looks prettier, which is a terrible reason =
to make changes in the core language at this point.</div>
<div><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div></div><=
/div></div></blockquote><div><br></div><div>You seem to be forgetting =
that the "abstract" suggestion I made is in relation to the =
OP's thread about "Group Member Specifiers". i.e. The OP was suggesting "pu=
blic, =3D0:" as a syntax as "a group specififer", probably to avoid a new w=
ord.</div><div><br></div><div>But pushing "=3D 0" to that position is ugly =
and not viable IMHO, where as "public, abstract:" as a "group spe=
cifier" is more viable if the OP's idea is going to get any traction, which=
is what I was trying to help with.</div><div><br></div><div>This is the to=
pic of the thread after all, and that context that shouldn't be forgotten h=
ere.</div><div><br></div><div>So *if* a word (I offered "abs=
tract") instead of =3D 0 is going to be accepted as a "group specifier=
", it's only right to float the idea as I did, that it could be also be use=
d in the same place as the "=3D 0" syntax where it is currently used, =
because:</div><div><br></div><div>* "=3D0" that is pretty ugly and *is=
n't easily searchable*.</div><div>* "abstract" is a consistent meaning=
here if we enable it somewhere else. Though will still have to search for =
both unless you using a conversion too, but that might be viable now.</div>=
<div>* *if* OP's proposal is to fly, something is needed, "=3D0" as a&=
nbsp;"group specifier" isn't viable.</div><div><br></div><div>I don't =
support " =3D abstract", I prefer just "abstract" with no =3D, on the basis=
that it suggests assignment and doesn't match other languages like c# or j=
ava. I think that's reasonable and also because c++ edges both ways wi=
th it's specififers like static void f().</div><div>There isn't a definite =
balance either way to my mind. It similarly fits with the ot=
her idea of allowing "public void f()" as well as "public: void f();"<=
/div><div><br></div><div>I prefer "abstract" over "pure" right now, because=
pure has other meanings to me and those meanings have appeared in other re=
cent proposals that may well happen. and "abstract" could be used on t=
he class too like some other languages </div><div><br></div><div>I don't fe=
el "=3D 0" will ever be deprecated either any time soon even if this propos=
al was to fly, just to be triple clear about my opinion on that.</div><div>=
<br></div><div>As I said before, none of this is strongly motivating to me,=
I'm just trying to make the OP's original ideas more viable and be support=
ive until it's time to conclude the evidence of all this and decide if it i=
s viable in the end.</div><div><br></div><div>Right now, I'm thinking this&=
nbsp;isn't viable as yet, but I'm open to seeing if enough supportive ideas=
can change that situation..</div><div><br></div><div> </div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-lef=
t:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-=
style:solid"><div><div><div dir=3D"ltr"><div><a href=3D"https://bitbucket.o=
rg/BillyONeal/" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.g=
oogle.com/url?q\75https%3A%2F%2Fbitbucket.org%2FBillyONeal%2F\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNEUaaIry0cea0l0vX6ztWgwQ7_4Lg';return true;" onclick=
=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fbitbucket.org=
%2FBillyONeal%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNEUaaIry0cea0l0vX6ztWgwQ=
7_4Lg';return true;">https://github.com/BillyONeal/</a></div><div><a href=
=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackov=
erflow.com%2Fusers%2F82320%2Fbilly-oneal\46sa\75D\46sntz\0751\46usg\75AFQjC=
NHY_gA133vyg0yY-U2PNMVA8cCSBg';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fusers%2F82320%2Fbi=
lly-oneal\46sa\75D\46sntz\0751\46usg\75AFQjCNHY_gA133vyg0yY-U2PNMVA8cCSBg';=
return true;">http://stackoverflow.com/<wbr>users/82320/billy-oneal</a></di=
v>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 23, 2013 at 7:45 AM, David R=
odr=EDguez Ibeas <span dir=3D"ltr"><<a>dib...@ieee.org</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;=
border-left-style:solid">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>On Mon, Dec 23, 2013 =
at 10:09 AM, David Krauss <span dir=3D"ltr"><<a>pot...@gmail.com</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div><span style=3D"color:rgb(34,34,34)">If the equals-sig=
n is a liability, and doesn't reflect the newer meaning related to definiti=
on, why keep it in "=3D abstract"? It's just confusing that defining a pure=
virtual function is supported, but not with an inline definition. (This fu=
rthermore makes the pure specifier incompatible with deduced return type.)<=
/span><br>
</div><div><div><br></div></div></blockquote></div><div>I agree in the firs=
t account, on the first quick read '=3D delete' and '=3D default' came to m=
ind, and 'overrides' and 'final' were left aside. The 'abstract'-like speci=
fier is more related to 'overrides' and 'final' than it is to the former.</=
div>
<div><br></div></div></div></div><div><div>
<p></p>
-- <br>
<br>
--- <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>std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></blockquote></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_8032_6176807.1388487173762--
.