Z
Zach
this is a rant. I want constness in C# the same way it is implemented
in C++. I'm not here to argue that C++ is superior to C# or C# sucks
or anything like that. They're both awesome languages when used for
the problem domains they excel at.
One thing C++ gets hands down correct though is constness. It would be
used something like this:
class A
{
public void DoSomethingUseful(const B parameter)
{
parameter.Member = 5; //Compilation fails
}
}
class B
{
public int Member = 0;
}
class Main
{
public static void Main(string[] args)
{
A a = new A();
B b = new B();
a.DoSomethingUseful(b);
}
}
This doesn't change the emitted IL at all. It's strictly a hint to
the compiler to throw an error when a violation is encountered. It is
immensely frustrating that with the current state of the language,
under no circumstances do I ever have any kind of guarantee about the
state of an object after invoking a function which takes an instance
of that object as an argument.
Take a collection for example. Collections should never need to
modify the state of the underlying object if you're simply asking for
the length. I know this is a blanket statement and I'm making it for
all past, current, and future collections that may ever exist, but
still, there is always "mutable" for the rare and crazy cases where
you want to break the law. In any case, why can't the Length()
function let the caller know as part of its signature that it plays
nice? Then, if I implement some serializer that serializes lists by
taking a reference to the list as an argument, that function can also
document that it plays nicely on lists by specifying the argument
const.
For anyone who's never used C++, I can't even begin to explain how
useful this is. But take my word that it results in better code. Not
better code than C#, just better code than it would if const didn't
exist.
Has anyone ever seen any rationale for why the language designers
opted not to add 'const' qualifiers?
in C++. I'm not here to argue that C++ is superior to C# or C# sucks
or anything like that. They're both awesome languages when used for
the problem domains they excel at.
One thing C++ gets hands down correct though is constness. It would be
used something like this:
class A
{
public void DoSomethingUseful(const B parameter)
{
parameter.Member = 5; //Compilation fails
}
}
class B
{
public int Member = 0;
}
class Main
{
public static void Main(string[] args)
{
A a = new A();
B b = new B();
a.DoSomethingUseful(b);
}
}
This doesn't change the emitted IL at all. It's strictly a hint to
the compiler to throw an error when a violation is encountered. It is
immensely frustrating that with the current state of the language,
under no circumstances do I ever have any kind of guarantee about the
state of an object after invoking a function which takes an instance
of that object as an argument.
Take a collection for example. Collections should never need to
modify the state of the underlying object if you're simply asking for
the length. I know this is a blanket statement and I'm making it for
all past, current, and future collections that may ever exist, but
still, there is always "mutable" for the rare and crazy cases where
you want to break the law. In any case, why can't the Length()
function let the caller know as part of its signature that it plays
nice? Then, if I implement some serializer that serializes lists by
taking a reference to the list as an argument, that function can also
document that it plays nicely on lists by specifying the argument
const.
For anyone who's never used C++, I can't even begin to explain how
useful this is. But take my word that it results in better code. Not
better code than C#, just better code than it would if const didn't
exist.
Has anyone ever seen any rationale for why the language designers
opted not to add 'const' qualifiers?