The character @ to abbreviate const

[Thaddeus H. Black]

Summary: const seems too frequent for a five-letter keyword. Has the single character @ to abbreviate const been considered for standardization?

Details follow.

In C++, one can write,

const auto a = foo();

However, one would rather write,

@auto a = foo();

or even

auto @a = foo();

I wish that @ were a standard abbreviation for const. Reason: frequent repetition of the five-letter keyword const clutters a source file.

(Similar considerations might or might not eventually lead one to consider @_iterator or @:iterator for const_iterator, etc.; but different issues are involved there, so today I ask only about @ for plain const.)

PAST CONSIDERATION

I suspect that members of the standards committee (whether individually or as a group) will have considered such questions in the past. However, I can find no Nxxxx paper to address such questions. Do you know of such a paper? If there exists no such paper, well, const-keyword clutter though technically trivial is practically significant. One realizes that there are historical reasons & and ^ have one-character symbols; but today, const must be 10 or 100 times as frequent. After all, imagine if one had to write alternate(foo, bar, baz) instead of foo ? bar : baz. Terse notation for frequent semantics is important.

MISAPPREHENSION BY BEGINNING STUDENTS OF C++

One reason I ask is that I have instructed engineering students in freshman-level beginning C++ at a U.S. university. That was a few years ago, pre-C++11, but my experience was that the majority of the students failed to grasp the significance of const during their first year. Even after I had assigned a special-purpose homework exercise to require the student to insert const everywhere possible/reasonable, the majority of the students failed to internalize the lesson. A standardized @ may seem trivial, but I suspect that it would help. The @ looks important. Since it is important, to make it look important might not be a bad thing.

PRAXIS IN OTHER LANGUAGES

It comes to my attention that the new programming language Rust reverses C++'s practice in the matter of constants and mutables. There are a zillion enthusiastic new upstart programming languages out there, of course, and C++ will not hurry to imitate them all, but let us pause for just a moment to consider: Rust assumes const. Rust apparently asks the programmer to type mut for "mutable" if constness is not wanted. Isn't that a good idea?

Well, C++ probably can't just reverse its own, established semantics like that; but might the standardization of @ not help? The word const seems too long (and, being alphanumeric, looks too much like an object identifier) for such frequent use. A @ might be better.

[Richard Hodges]

Oh god, please no!

The language should continue to evolve to be less cryptic and more readable. Introducing magic symbols is the opposite of that.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.

[Thiago Macieira]

On Sunday, 30 July 2017 07:38:25 PDT Thaddeus H. Black wrote:
> Summary: const seems too frequent for a five-letter keyword. Has the single
> character @ to abbreviate const been considered for standardization?
>
> Details follow.
>
> In C++, one can write,
>
> const auto a = foo();
>
> However, one would rather write,
>
> @auto a = foo();

Do you really think you would rather write:

static char @ * @ array[] = { "abc", "def" };

Anyway, the big problem is that @ is not in the basic charset.

2.3 [lex.charset] says:

> The basic source character set consists of 96 characters: the space
> character, the control characters representing>
> horizontal tab, vertical tab, form feed, and new-line, plus the following 91
> graphical characters:
>
> a b c d e f g h i j k l m n o p q r s t u v w x y z
> A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
> _ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ~ ! = , \ " ’

@ is not listed. That means we may have to support character encodings where @
is not present. In turn, that means we may need a digraph for it.

In any case, there have been discussions about extending the character set and
they usally end up nowhere. But the consensus seems to be that if we want to
do it, it has to be for a pretty good reason. I don't think a 4-character
shrinking of a keyword would meet that requirement.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Tony V E]

I think we could easily add @ to the character set (but maybe not for this use). 

Anyone that complains that they don't have a @ key can just *email* us. :-)


Sent from my BlackBerry portable Babbage Device
  Original Message  
From: Thiago Macieira
Sent: Sunday, July 30, 2017 12:37 PM
To: std-dis...@isocpp.org
Reply To: std-dis...@isocpp.org
Subject: Re: [std-discussion] The character @ to abbreviate const

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-discussio...@isocpp.org.

[Nicol Bolas]

On Sunday, July 30, 2017 at 11:16:04 AM UTC-4, Richard Hodges wrote:

Oh god, please no!

The language should continue to evolve to be less cryptic and more readable. Introducing magic symbols is the opposite of that.

I disagree with that idea in the general case. There are many times when a well-understood symbol is easier to read and comprehend than a long word.

Consider `std::forward`. There's a proposal to replace it with a symbol. This is in part because of how incredibly verbose it is, particularly in template code where the type being forwarded has to be deduced:

[](auto &&...args) {some_func(std::forward<decltype(args)>(args)...);}

Understanding what that code is trying to do is a lot harder than:

[](auto &&...args) {some_func(>>args...);}

If you understand that `>>` means "forward", then its clear what the code is accomplishing: it's taking parameters and forwarding them to some other function. Why does the first one have `decltype(args)`? Because by the rules of C++, it needs to be there. That added syntax is pointless noise to the reader.

So I disagree with the general notion that a short symbol cannot be more effective than a long word.

The problem with the proposed symbol (besides the fact that it's being asked in the wrong forum) is not that it's a symbol. It's that it doesn't buy much.

Adding a symbol increases the difficulty of understanding the language. If it is to be done, it must be counter-balanced by what that symbol provides, relative to the alternatives. `[]` for lambdas was choose in part because lambdas greatly benefit from being short. `>>` purchases its place (if you agree with the proposal) because of circumstances like the above. You remove pointless noise from an otherwise comprehensible expression.

`@` doesn't do any of that. It saves at most 5 characters. And it doesn't even look very much like "const". There are no other const-using languages that use the `@` symbol, so that raises the bar for understanding it. At least `>>` looks vaguely like it might be pointing "forward"; `@` is just a conveniently unused symbol.

Overall, it just doesn't improve code clarity enough to be worth the mental gymnastics of having to learn yet another symbol.

[Nicol Bolas]

On Sunday, July 30, 2017 at 12:40:28 PM UTC-4, Tony VE wrote:

I think we could easily add @ to the character set (but maybe not for this use). 

Anyone that complains that they don't have a @ key can just *email* us. :-)

I wouldn't be too sure. As I understand it, one of the reasons the reflection proposal had to back away from using `$` instead of a keyword `reflexpr` is that some language extension to C++ somewhere already gave `$` special meaning. Similarly, we can't give `^` special powers, because several C++ extensions already use that.

These days, the problem isn't so much that we can't expand the character set. It's that other people have already done so, and we don't want to break their extensions.

[Ville Voutilainen]

On 30 July 2017 at 19:46, Nicol Bolas <jmck...@gmail.com> wrote:
>> Anyone that complains that they don't have a @ key can just *email* us.
>> :-)
> I wouldn't be too sure. As I understand it, one of the reasons the
> reflection proposal had to back away from using `$` instead of a keyword
> `reflexpr` is that some language extension to C++ somewhere already gave `$`
> special meaning. Similarly, we can't give `^` special powers, because

There are tools that do very naive parsing of code embedded in C++
(actually whatever language) code, and some of those
tools use $ as a delimiter for what they should parse. None of those
tools are going to embed
a C++ compiler unless they absolutely have to. Not all of those tools
parse things that appear
only in comments. They are not really language extensions, they are
stand-alone tools that have no idea
how to parse any of C++. To some extent they are similar to the
preprocessor, and they are indeed preprocessors.

[Thiago Macieira]

On Sunday, 30 July 2017 09:40:25 PDT Tony V E wrote:
> I think we could easily add @ to the character set (but maybe not for this
> use).
>
> Anyone that complains that they don't have a @ key can just *email* us. :-)

Is our UUCP gateway working?

[Ville Voutilainen]

On 30 July 2017 at 20:27, Thiago Macieira <thi...@macieira.org> wrote:
> On Sunday, 30 July 2017 09:40:25 PDT Tony V E wrote:
>> I think we could easily add @ to the character set (but maybe not for this
>> use).
>>
>> Anyone that complains that they don't have a @ key can just *email* us. :-)
>
> Is our UUCP gateway working?

Whether anyone uses bang-paths any more is beside the point. Just
because people can write
a @ doesn't make it a good idea to use it as a character in C++. I
don't know of other tools off-bat
besides doxygen that use it, and doxygen already parses C++ to some
extent. The question
is whether other tools with more naive parsers use it, and whether we
are going to break such
tools.

[Thaddeus H. Black]

Nicol and Ville write:

> These days, the problem isn't so much that we can't expand the character set. It's that other people have already done so, and we don't want to break their extensions.

> They are not really language extensions, they are stand-alone tools that have no idea how to parse any of C++.

These are good points. The points are conceded.

Nevertheless, my experience teaching C++ to 18- and 19-year-old engineering beginners is that they are not getting the point of const until six months after they should. This tells me that the language (C++) and the instructor (me) are letting them down. The letdown is not for lack of effort on the language's or instructor's part. The problem seems to be structural.

Seen in hindsight, when first invented, C and especially C++ should probably have defaulted to const, allowing mutability only by explicit specification. For historical reasons, of course, that didn't happen. Today, to you and me, typing const over and over (and over and over and over) is a minor irritation, but it's a pretty big obstacle to C++ programmers with fewer than two years of serious coding experience. They don't even know all the places they can type const. Besides, observe how persistent the often unnecessarily constless traditional definition int main(int argc, char **argv) has remained—even among experienced programmers who should arguably know better. After all, who likes to type

int main(const int argc, const char *const *const argv)

even if that is what he or she really means?

In a related matter, it seems to me that the language ought to syntactically express the logical relationship between the likes of iterator and const_iterator. The existing identifiers work, of course, when handled by the sufficiently experienced, but they still do not feel quite right, do they?

So, maybe @ is not the right solution, but C++ needs something. It could use some better syntax to express the various semantics of const and maybe const_.

[Thiago Macieira]

On Sunday, 30 July 2017 11:28:10 PDT Thaddeus H. Black wrote:
> Besides, observe how
> persistent the often unnecessarily constless traditional definition int
> main(int argc, char **argv) has remained—even among experienced programmers
> who should arguably know better. After all, who likes to type
>
> int main(const int argc, const char *const *const argv)
>
> even if that is what he or she really means?

They are constless because they are mutable. A lot of command-line parsing
algorithms modify argc and rearrange the items in argv.

[Nicol Bolas]

On Sunday, July 30, 2017 at 2:28:10 PM UTC-4, Thaddeus H. Black wrote:

Nicol and Ville write:

> These days, the problem isn't so much that we can't expand the character set. It's that other people have already done so, and we don't want to break their extensions.

> They are not really language extensions, they are stand-alone tools that have no idea how to parse any of C++.

These are good points. The points are conceded.

Nevertheless, my experience teaching C++ to 18- and 19-year-old engineering beginners is that they are not getting the point of const until six months after they should. This tells me that the language (C++) and the instructor (me) are letting them down. The letdown is not for lack of effort on the language's or instructor's part. The problem seems to be structural.

I do not see any way in which making `const` a symbol would solve that problem. Understanding the reason for a piece of syntax, generally speaking, has little to do with how many characters it takes.

Seen in hindsight, when first invented, C and especially C++ should probably have defaulted to const, allowing mutability only by explicit specification. For historical reasons, of course, that didn't happen. Today, to you and me, typing const over and over (and over and over and over) is a minor irritation, but it's a pretty big obstacle to C++ programmers with fewer than two years of serious coding experience. They don't even know all the places they can type const. Besides, observe how persistent the often unnecessarily constless traditional definition int main(int argc, char **argv) has remained—even among experienced programmers who should arguably know better. After all, who likes to type

int main(const int argc, const char *const *const argv)

even if that is what he or she really means?

I fail to see how using a symbol would in any way encourage that. I for one would in no way be more willing to write the symbolized-`const` version of `main` than the keyworded version.

I think you have too great an expectation of how much `const` usage we ought to have. For example, there is absolutely no correctness problem with `argc` not being `const`, so why should you force it to be so? And I think your premise is ultimately flawed: making `const` shorter to type will not make its use more prevalent.

C++ is not a functional programming language. We have mutable state, and that's not a bad thing. The sooner programmers accept that, the better.

[Thiago Macieira]

On Sunday, 30 July 2017 12:27:30 PDT Nicol Bolas wrote:
> I do not see any way in which making `const` a symbol would solve that
> problem. Understanding the reason for a piece of syntax, generally
> speaking, has little to do with how many characters it takes.

I'd actually say that it's easier if it spells out something that resembles a
word, better yet if it does. Otherwise, students will be wondering why
sometimes they write "auto" and sometimes "@auto".

[Nevin Liber]

On Sun, Jul 30, 2017 at 9:38 AM, Thaddeus H. Black <thaddeus...@gmail.com> wrote:

In C++, one can write,

const auto a = foo();

However, one would rather write,

@auto a = foo();

I wish that @ were a standard abbreviation for const. Reason: frequent repetition of the five-letter keyword const clutters a source file.

MISAPPREHENSION BY BEGINNING STUDENTS OF C++

One reason I ask is that I have instructed engineering students in freshman-level beginning C++ at a U.S. university. That was a few years ago, pre-C++11, but my experience was that the majority of the students failed to grasp the significance of const during their first year.

I don't see how:

1. "Misapprehension by beginning students of C++" has anything to do with "clutters a source file."
2. Adding a shorter cryptic synonym helps beginning students "grasp the significance of const". 

Even after I had assigned a special-purpose homework exercise to require the student to insert const everywhere possible/reasonable, the majority of the students failed to internalize the lesson. A standardized @ may seem trivial, but I suspect that it would help. The @ looks important. Since it is important, to make it look important might not be a bad thing.

Is it that important?  Going back to your initial example:

const auto a = foo();

Sure, you can do this, but I've never found it all that important and only marginally useful to mark local variables (auto or not) as const.  I'm much more concerned with references/pointers to const and const member functions.

Rust apparently asks the programmer to type mut for "mutable" if constness is not wanted. Isn't that a good idea?

I certainly would prefer that, but that ship sailed long ago.  However, that doesn't seem to be an argument in favor of making const vs. mutable less visually distinct.

--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404

[Thaddeus H. Black]

Nevin summarizes why my @ idea won't work, thanks. Permit me to concede the point.

However, the @ idea was mistargeted at a larger issue.

On Sunday, July 30, 2017 at 7:27:30 PM UTC, Nicol Bolas wrote:

C++ is not a functional programming language.

Yes but C++ is a multiparadigm programming language. That's what makes it so great.

You have correctly intuited that I believe that C++ wants improved functional support, but I am a 49-year-old electrical engineer without a C.S. degree, so my position (alas) is an entirely practical position rather than a theoretical or ideological one.

Functional is a paradigm. To the extent to which I have voluntarily chosen the functional paradigm in a certain module of my program, I would like the compiler to competently enforce the paradigm I have chosen. Competent enforcement of paradigms yields correct code. If I did not want the compiler to enforce a paradigm, then I'd be happy programming in plain C.

We have mutable state, and that's not a bad thing.

But often it is a bad thing, isn't it, especially for concurrency. I would like C++ to provide more convenient, optionally activated, compiler-enforced support to help me consistently to avoid the bad thing. Wouldn't you?
 

The sooner programmers accept that, the better.

If you were saying that future C++ standards were incapable of gaining first-class support for the functional paradigm, then I would hope that you were mistaken. We already have lambdas, so C++'s trend fortunately is good.

Like you, I have a lot of years invested in C++. Compiler and library developers have even more invested. To see an alternate language like Rust displace C++ would hardly benefit any of us. Rust is young; C++ still has time to adapt, but only to the extent that C++ continues (at it always has done) to admit where a problem exists. For now, C++'s support for reliably correct multicore logic is lagging a bit, but C++ has been making good progress and I want to help it to catch up.

In my judgment, Rust is the greatest threat to dethrone C++ we have seen in 20 years. I like Rust. One could reply, "If you like Rust, then go tell the Rust mailing list!" But that was not my point. Many C++ programmers like Rust. Rust has a lot to like but (for now) is still lacking in libraries, tools, polish and implementation experience. C++ will learn Rust's main lessons or gradually (over many years) follow the once-mighty Fortran into fading irrelevance, I predict. The tipping point lies still years away but it does exist. Rust is no Java, Python, Haskell or Go, for Rust directly, credibly targets C++'s primary application domain.

I get that my punctuator @ is probably the wrong answer. I would like to hear the right answer if anyone knew it.

[Nicol Bolas]

On Sunday, July 30, 2017 at 4:48:19 PM UTC-4, Thaddeus H. Black wrote:

Nevin summarizes why my @ idea won't work, thanks. Permit me to concede the point.

However, the @ idea was mistargeted at a larger issue.

On Sunday, July 30, 2017 at 7:27:30 PM UTC, Nicol Bolas wrote:

C++ is not a functional programming language.

Yes but C++ is a multiparadigm programming language. That's what makes it so great.

You have correctly intuited that I believe that C++ wants improved functional support, but I am a 49-year-old electrical engineer without a C.S. degree, so my position (alas) is an entirely practical position rather than a theoretical or ideological one.

Functional is a paradigm. To the extent to which I have voluntarily chosen the functional paradigm in a certain module of my program, I would like the compiler to competently enforce the paradigm I have chosen.

You can't. That is, in fact, the whole point of a multi-paradigm language. The compiler can allow you to live within whichever paradigm you choose. But in order to allow different people to choose different paradigms, it cannot impose a paradigm upon you. Multi-paradigm languages allow; they do not enforce.

C++ lets you live in an object-ordered world until the very moment it becomes disadvantageous to your needs, so you then back-door out to structured programming for a while, then maybe use some functional range stuff because why not, then go back to your OOP world.

That is what multi-paradigm programming means. And you can't do that if you impose the strictures of a functional paradigm. Or an OOP paradigm. Or a structured paradigm.

Competent enforcement of paradigms yields correct code. If I did not want the compiler to enforce a paradigm, then I'd be happy programming in plain C.

We have mutable state, and that's not a bad thing.

But often it is a bad thing, isn't it, especially for concurrency.

And if I'm not doing concurrency? Or more to the point, what if I've segregated concurrency into a minimal area, with as little cross-talk as possible and tightly controlled exchanges of data? What good is stopping me from having mutable state in such an application?

I would like C++ to provide more convenient, optionally activated, compiler-enforced support to help me consistently to avoid the bad thing. Wouldn't you?

No. I personally prefer to make "bad things" impossible, rather than rely on some "optionally activated" thing.

The sooner programmers accept that, the better.

If you were saying that future C++ standards were incapable of gaining first-class support for the functional paradigm, then I would hope that you were mistaken. We already have lambdas, so C++'s trend fortunately is good.

Lambdas exist in C++ because lambdas are useful to C++ programmers, not because the functional model is the One True Way to program and C++ is trying to be more functional. "Gaining first-class support for the functional paradigm" is not a priori a positive direction for C++.

Integrating useful features that happened to originate from a different paradigm should not be construed as C++ shifting to be more like that paradigm.

Like you, I have a lot of years invested in C++. Compiler and library developers have even more invested. To see an alternate language like Rust displace C++ would hardly benefit any of us.

How do you figure? I know pretty much nothing about Rust. But if it truly were able to displace C++, that must mean that it is a better language for stuff C++ does well. So how exactly is switching to a better language not of benefit to us?

I'm flexible about what programming language I use; I'm perfectly capable of adapting to whatever is out there. I've gone from C-in-classes to more modern C++ paradigms. I've gone from minimal standard library usage to more range-like mechanisms. And so forth.

If Rust becomes the new paradigm, I'll adapt.

And the fact is this: you're never going to make a Rust-like C++. It's simply impossible. Changes to C++ require backwards-compatibility; the committee is not going to break the world. So long as you can't do anything that's substantially incompatible with what came before, you will be unable to make the kinds of changes you seem to think the language needs.

Const-by-default and immutability are in the "not gonna happen" category.

[Matthew Woehlke]

On 2017-07-30 14:28, Thaddeus H. Black wrote:
> Nevertheless, my experience teaching C++ to 18- and 19-year-old engineering
> beginners is that they are not getting the point of const until six months
> after they should.

> [...]

> int main(const int argc, const char *const *const argv)

Well, it doesn't help that you're using the confusing placement. If you
consistently write `type const` instead of `const type`, you don't have
to think so much about what is being made `const`... it's always the
thing to the left of `const`...

(I know of at least one library that has a broken API due to this
issue... lots of `const POINTER_T` when they obviously really wanted
`POINTER_CONST_T`.)

--
Matthew

[Matthew Woehlke]

On 2017-07-30 13:36, Ville Voutilainen wrote:
> Whether anyone uses bang-paths any more is beside the point. Just
> because people can write a @ doesn't make it a good idea to use it as
> a character in C++. I don't know of other tools off-bat besides
> doxygen that use it,

...and it's totally optional in doxygen; I don't believe there is
anywhere you could use a `@` that you cannot use a `\` instead. (In
fact, I'm not sure but what doxygen doesn't accept `@` solely for the
sake of similarity to javadoc...)

--
Matthew

[Thiago Macieira]

On domingo, 30 de julho de 2017 09:46:18 PDT Nicol Bolas wrote:
> I wouldn't be too sure. As I understand it, one of the reasons the
> reflection proposal had to back away from using `$` instead of a keyword
> `reflexpr` is that some language extension to C++ somewhere already gave
> `$` special meaning. Similarly, we can't give `^` special powers, because
> several C++ extensions already use that.

Specifcally for @, Objective C++ uses it.

[Richard Hodges]

Specifcally for @, Objective C++ uses it.

This is historical is it not? Objective-C started out as a bunch of template preprocessor markup to handle all the boilerplate when writing a messaging protocol in C (more or less). Its syntax today is a direct legacy of that, and notably loathed by all who have used it.

FWI I have been writing C and C++ for 30 years. I was writing code when the const keyword was invented (at the time C went from K&R's brainchild to an ISO standard, no?). Not once in that time have I ever thought, "By God Sir, having to type these 4 characters is an outrage!"

I agree with the view that std::forward<XXX>() is cumbersome, but vehemently disagree that ">>" is anything but obfuscation. Adding a keyword called (say) forward, or fwd would be less cryptic while arguably improving ease of writing code and maintainability.

e.g.:

x = foo(forward p);

or 

y = bar(forwarded q);

or

z = baz(fwd r);

but this:

x = foo(>>p);  

Is utterly cryptic. It trades a few keystrokes for the need to perform a mental transformation. There is no easy mental conversion from >> (unary right shift?) to the concept of "a forwarded argument", at least for me. It is IMHO overuse of this kind of arcane symbology that discourages me from getting involved in otherwise great languages like Haskell and Ruby.

R

 

 

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.

[Thiago Macieira]

On segunda-feira, 31 de julho de 2017 23:40:53 PDT Richard Hodges wrote:
> > Specifcally for @, Objective C++ uses it.
>
> This is historical is it not?

Does it matter?

It's used in a very important and widely used extension of the C++ language.

[Thaddeus H. Black]

On Sunday, July 30, 2017 at 11:20:55 PM UTC, Nicol Bolas wrote:

On Sunday, July 30, 2017 at 4:48:19 PM UTC-4, Thaddeus H. Black wrote:

Functional is a paradigm. To the extent to which I have voluntarily chosen the functional paradigm in a certain module of my program, I would like the compiler to competently enforce the paradigm I have chosen.

You can't.

Can't I?
 

That is, in fact, the whole point of a multi-paradigm language. The compiler can allow you to live within whichever paradigm you choose.

True.
 

But in order to allow different people to choose different paradigms, it cannot impose a paradigm upon you.

If I ask it to, why can't it?
 

Multi-paradigm languages allow; they do not enforce.

Don't they? C++ enforces strong typing, for example. C++ enforces lots of things, if asked (mostly via its type system).

I would prefer that C++ allow me to ask it to enforce many more things than it does, some of them with block scope.

C++ needs something. I do not know what, but something. C++ has never allowed itself to become archaic before, but in my opinion there is a real danger here. Having taught hundreds of undergraduates their first semester of C++ programming, I say that mutable-by-default is a problem. Perhaps it is one of many problems that might be fixed by new enforcement mechanisms. What those mechanisms should be, I do not know.

I do not have a solution.

[Thiago Macieira]

On Monday, 7 August 2017 16:47:45 PDT Thaddeus H. Black wrote:
> On Sunday, July 30, 2017 at 11:20:55 PM UTC, Nicol Bolas wrote:
> > On Sunday, July 30, 2017 at 4:48:19 PM UTC-4, Thaddeus H. Black wrote:
> >> Functional is a paradigm. To the extent to which I have voluntarily

> >> chosen the functional paradigm in a certain module of my program, *I

> >> would like the compiler to competently enforce the paradigm I have

> >> chosen.*

> >
> > You can't.
>
> Can't I?

No, because:

> > But in order to allow different people to choose different paradigms, it

> > cannot *impose* a paradigm upon you.

>
> If I ask it to, why can't it?

Because "it" here is the standard, not the compiler. The standard cannot
impose one paradigm only and there's no such thing as choices inside it. All
options and paradigms need to be specified.

If you want a compiler switch that enforces some things, feel free to ask of
your vendor. For example, GCC has -Werror=effc++.

[Viacheslav Usov]

On Tue, Aug 8, 2017 at 3:26 AM, Thiago Macieira <thi...@macieira.org> wrote:

> No, because:

Sure we can. Just like by writing class X { ... } we can enforce whatever is defined within the braces to be member of class X.

In this particular case, we can also think of scopes with whatever new kind of enforcement (I know that this a discussion or the proposals forum). Or we can think of using-like directives that work in some other way. Fro example, we could propose that "using const auto" makes every "auto" introduce a constant, and "mutable auto" would need to be specified for mutable variables.

I am not making any concrete proposal, I am just pointing out that it is possible to propose a way to enforce such a constraint, despite C++ being multi-paradigm.

Cheers,

V.

[Cleiton Santoia]

Do you really think you would rather write:

        static char @ * @ array[] = { "abc", "def" };

I think that is just about to "get used to it"

One also could imagine the opposite... instead of '&' we could use a "refer" keyword to "improve readability"

const std::string refer concat(const std::string refer a, const std::string refer b) {  // this is strange
...
}

However, I recall a proposal that introduces a way to save some 'consts' typing http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3955.pdf , but it was rejected, but I don't know why...

[Nicol Bolas]

There is a difference between enforcing a constraint, and enforcing a paradigm, which is what the OP is ultimately talking about.

`const` defines a constraint on an object (though of course, `const_cast` and `mutable` allow you to break that constraint). But `const` does not enforce a programming paradigm on the user or even over a region of code.

Enforcing a paradigm would be like saying "you can't use stateful lambdas" or "you can't use inheritance-based polymorphism" or "there can be no global state".

[Fabio Fracassi]

On 08.08.17 17:48, Cleiton Santoia wrote:
>
> However, I recall a proposal that introduces a way to save some
> 'consts' typing
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3955.pdf ,
> but it was rejected, but I don't know why...
>

> --


The argument was that group specifiers make it harder to do maintenance,
since it is code becomes dependent on its position, which can be more
easily missed in code/patch review.

[Thiago Macieira]

On Tuesday, 8 August 2017 02:09:00 PDT Viacheslav Usov wrote:
> On Tue, Aug 8, 2017 at 3:26 AM, Thiago Macieira <thi...@macieira.org> wrote:
> > No, because:
> Sure we can. Just like by writing class X { ... } we can enforce whatever
> is defined within the braces to be member of class X.

That's not the same.

Enforcing a paradigm is reducing the way one can program to conform to that
particular paradigm. For example, if we wanted for enforce OOP programming
paradigm, we could say that all functions must be members of a class and
forbid free functions; we could also make functions virtual by default or only
virtuals. Like Java.

Instead, C++ does not force you to the OOP paradigm. You can choose it, or do
procedural programming, or functional, or mix and blend them however you wish
to.

> In this particular case, we can also think of scopes with whatever new kind
> of enforcement (I know that this a discussion or the proposals forum). Or
> we can think of using-like directives that work in some other way. Fro
> example, we could propose that "using const auto" makes every "auto"
> introduce a constant, and "mutable auto" would need to be specified for
> mutable variables.

I don't think that's likely to be accepted, though to be honest I don't think
it's ever been proposed. Maybe you should write a paper and see how the
community reacts.

[Viacheslav Usov]

On Wed, Aug 9, 2017 at 5:11 AM, Thiago Macieira <thi...@macieira.org> wrote:

> Enforcing a paradigm is reducing the way one can program to conform to that particular paradigm.

C++ has means to enforce various user-chosen constraints in a particular region of code. It is not unthinkable that it can have more of such means. The latter is what the OP essentially wants.

The "constraints" vs "paradigms" talk is arguing semantics.

Cheers,

V.

[Cleiton Santoia]

Thanks.... I liked that proposal... :(  

However, we could say the same about private/protected/public, don't we ?

[Fabio Fracassi]

Yes, but that is water under the bridge.