equivariant functions

[Andrei Alexandrescu]

Benji Smith wrote:
> Hey, Andrei!
> 
> First of all, just let me say how much I appreciate your detailed 
> responses. I hope you don't ever take my feedback as a personal 
> criticism or as being harshly negative. The only reason I've continued 
> to engage is these kinds of debates for the last five years or so is 
> because D interests me very much, and I'd like to see it meet its 
> fullest potential. I know you have the same end-goals in mind, though we 
> sometimes disagree about the most effective route from point A to point B.

That is highly appreciated.

> Andrei Alexandrescu wrote:
>> I see where you're coming from. If your opinion is that the const 
>> system does not bring enough benefits to justify its learning, you are 
>> of course entitled to it. But talking about complexity implies that 
>> there would be simpler ways to achieve its charter that we missed, and 
>> talking about holes that we made mistakes of principle that go beyond 
>> bugs in the compiler or incompleteness of implementation.
> 
> Yeah, I see where you're coming from too. I think you guys have done an 
> admirable job thinking through the corner cases and figuring out ways to 
> solve many of the sticky design issues that have arisen.
> 
> On the other hand, there was a const proposal...maybe six months or a 
> year ago...where all function parameters would be considered immutable 
> by default, unless annotated as mutable.

Sure. I suggested that to Walter two years ago, or maybe three. It was 
one of the first suggestion I made: you should make everything immutable 
by default, and mutable only if explicitly specified. (That's what e.g. 
ML and Cecil do.) He also liked it: instead of littering code with const 
this and immutable that, you only have var here and there - and maybe 
mutation is much less rarely needed than we think. In the end we 
rejected the idea because we thought it'll scare away people coming from 
C++ and Java. It was also too big a change from what D was at that 
point. So we had to drop that.

But don't think for a moment that that approach would have been one iota 
simpler than what we have now. Supporting mutation and immutability in 
the same range is a sort of constant-sum game - you can pick your 
defaults, but overall the pie has the same size.

> I thought that idea had a lot of merit. My first impression was that 
> it'd provide more reliable guarantees, since it would be impossible to 
> accidentally create a mutable param by forgetting to declare its 
> constness. It also seemed like it would have resulted in more compact 
> method signatures (since const arguments are generally more common than 
> mutable arguments), and less overall risk of aliasing.
> 
> For me, one of the main perks of the other proposal was less "const" 
> litter all over the code, and yet with stronger const safety.

You'll be glad then to learn that "in" means const at least in D2:

void foo(in char[] s); // same as foo(const(char)[] s)

> Also, a function promising not to modify its arguments seems more like 
> an attribute of the function, not of the arguments themselves.

The signature of the function _is_ an attribute of the function.

> But I digress...

It's a good digression.

> Driving a car with a manual transmission requires a more detailed mental 
> model than driving an automatic. Maybe the manual transmission offers 
> other advantages, but ease-of-use is not one of them.

Hmmmm. I'd compare the wild west when everything is mutable at any time 
much more with an unwieldy manual-transmission car that leaks oil and 
blows a gasket every so often. That's congruent with my earlier point: 
you think const is more trouble for you. IMHO it's exactly, but I mean 
exactly, the opposite.

> I actually plan on giving D2 a spin as soon as a compatible version of 
> Tango is available.
[snip]
> But the const system just smells bad to me. I've tried to enumerate my 
> reasons, and maybe switching to D2 will change my mind. But right now, 
> I'm calling it as I see it. You asked for feedback, and you got it!!

Now I'm not sure how to sugarcoat or spin positively or put nicely what 
I'm going to say. Let me try (actually it took me a couple of minutes to 
figure out a formula).

At least to me, "feedback" implies a closed-loop system. Stuff happens, 
has consequences, the consequences are observed, and information is 
"fed" "back" to the system. In our case, I'd say that using const is an 
absolute prerequisite for feedback to be taken seriously, particularly 
when it's as informal as "just smells bad to me". Otherwise I think 
"candid opinion" is the best way I can put it. Sorry.

[snip]
> Since this community presumably exists to support a collaborative 
> environment for advancing the D language (and does a remarkably good job 
> of it in the vast majority of cases), I just wanted to put my vote in 
> the ballot-box.
> 
> :-)

Please get information on the candidate before voting.

Andrei