Something like "readonly"?

[Stefan Ram]

In Java, I am used to write code like:

void f( final int i ){ final int j = g( i ); ... }

. But neither »const« nor »readonly« in C# seem
to be apppropriate for this purpose.

The intention is to enhance readability of source
code by conveying the intention that

- the parameter i will not be changed within
the body and that

- the variable j will not be changed after its
initialization.

Something similar is possible with »const« in C
and C++.

 

[Jeroen Mostert]

In Java, I am used to write code like:

void f( final int i ){ final int j = g( i ); ... }

. But neither »const« nor »readonly« in C# seem
to be apppropriate for this purpose.

The intention is to enhance readability of source
code by conveying the intention that

- the parameter i will not be changed within
the body and that

- the variable j will not be changed after its
initialization.

Something similar is possible with »const« in C
and C++.

There is nothing similar for local variables in C#. If there were it
probably would have been "readonly" for locals, but there isn't.

Much like C++'s "const", this is one of those things I don't really miss.
It's easy to compensate for by not writing methods large enough to need such
hints in the first place. For parameters it's certainly unnecessary if you
simply heed the rule to never modify them in the first place (adding these
hints to prevent others from doing this is unnecessary or ineffective,
depending on your successor's level).

That's not to say anyone who does like these things is "doing it wrong", and
I would be the first to cheer better support for immutability added to the
language, of the kind that can help you with concurrency -- C++'s "const"
isn't quite it.

 

[Arne Vajhøj]

In Java, I am used to write code like:

void f( final int i ){ final int j = g( i ); ... }

. But neither »const« nor »readonly« in C# seem
to be apppropriate for this purpose.

The intention is to enhance readability of source
code by conveying the intention that

- the parameter i will not be changed within
the body and that

- the variable j will not be changed after its
initialization.

Something similar is possible with »const« in C
and C++.

If one want to do functional programming, then my
suggestion would be to use a functional language.

I don't like the practice used by some to sprinkle final
all over Java code.

I would only use it if necessary (inner classes).

Arne

 

[Arne Vajhøj]

There is nothing similar for local variables in C#. If there were it
probably would have been "readonly" for locals, but there isn't.

Much like C++'s "const", this is one of those things I don't really
miss. It's easy to compensate for by not writing methods large enough to
need such hints in the first place. For parameters it's certainly
unnecessary if you simply heed the rule to never modify them in the
first place (adding these hints to prevent others from doing this is
unnecessary or ineffective, depending on your successor's level).

That's not to say anyone who does like these things is "doing it wrong",
and I would be the first to cheer better support for immutability added
to the language, of the kind that can help you with concurrency -- C++'s
"const" isn't quite it.

C++ const is a must to get some C++ code to work.

And I actually miss the C++ const in both Java and C#.

Arne

 

[Jeroen Mostert]

C++ const is a must to get some C++ code to work.

I'm not really sure what the statement is, here. C# "class" is a must to get
most C# code to work. Less flippantly, checked exceptions are a must to get
some Java code to work. The language itself is a poor yardstick for its
features.

In a legal C++ program you should be able to erase "const" everywhere
(including every place it's mentioned in the standard, and duplicate
overloads) and still end up with a working program, right? It's been a few
years since I've hacked C++ in a serious way, so maybe I'm overlooking
something.

And I actually miss the C++ const in both Java and C#.

Like I said, different strokes. I haven't yet written a piece of C# code
where I thought "gee, if only I had const here" because it wouldn't have
added anything to the code. The one exception being immutability for
concurrency, as I mentioned. In frameworks, readonly properties and the
occasional read-only collection are usually sufficient, and even then
frameworks are not the majority of code. C++ code involves "const" even in
places where it's not buying you anything, other than a slightly misplaced
feeling of safety.

....but I really don't want to continue discussing the merits of "const", as
that must have been done to death. I'm certainly not going to tell C++
programmers how to do their jobs.