Do we really need const?

[renoX]

Regan Heath a écrit :
> Bill Baxter wrote:
>> Regan Heath wrote:
>>> renoX wrote:
>>>> Bruce Adams a écrit :
>>>>> An example of one that catches me out quite often is:
>>>>> strcpy(src,dest) vs. strcpy(dest,src);
>>>>
>>>> If it helps you'not the only one to have this kind of issue: some 
>>>> compilers even try to detect when people makes mistakes for 'memset'?
>>>> Both case show why function calls with passing the parameter by 
>>>> position instead of by keywords *sucks*.
>>>>
>>>> Let's try it: do you think you would make the same mistake if you 
>>>> would call your function this way:
>>>> char[50] var_dest, my_src;
>>>> strcpy(dest: var_dest, src: my_src)
>>>
>>> My eyes... aaarghh!
>>
>> Is it the particular syntax or the concept you object to?  
> 
> Not sure, it just makes my skin crawl at the moment.  I've never really 
> had a problem with passing arguments in the wrong order.  These days my 
> IDE prompts me as I type, that feature seems to remove the need for this 
> idea completely, to my mind.  Granted not every IDE has this.
> 
> It's a bit like the idea to use 'out'/'ref' 'inout' etc at call site.  I 
> can understand the argument that it increases the information available 
> to someone simply reading the code but I just don't want to have to type 
> all that.

The IDE can write these thing for you (assuming of course you write the 
function prototype before the call), and for maintained code, there is 
more reading/rereading than writing.

> Again, an IDE could easily display this information for you.  But again, 
> not every IDE will have such a feature and if you decided to display the 
> source in another form (printed or something) you loose the information 
> again.

Yes, that's why having the IDE writing additional information for you is 
better: everyone benefits from it, whereas if those information are 
displayed only when you have an IDE, only the users with the IDE will 
have those information..

> I guess all I'm saying is that I'm on the other side of the fence, the 
> gain from these additions are less than the cost, to me.

As said above, developers spend more time reading code (for debugging, 
for modifying) than writing code.

>  > I think
>> named/keyword parameters can be quite useful.  Have you ever used a 
>> language that has them?
> 
> To be fair, no, and I should probably try it before passing judgement.
> 
> My last post was a 'first impression' or rather, 'another first 
> impression' because I recall this idea being posted before, perhaps 
> several times.
> 
>> I think the problem with putting them into D is only that it becomes 
>> yet another way to do things.  We already have all the flavors of 
>> overloading inherited from C++.

I don't follow you here, having keyword function call doesn't imply that 
you necessarily allow different a overloading mode..

Sure D could also use the name of the parameters as a disambiguator 
[which is nice IMHO sin(deg: 90) and sin(rad: pi) is better than sin_deg 
and sin_rad] but this is not *required*.

And IMHO, it wouldn't be wise to add this parameter name overloading at 
first, because as you said the interactions between this an normal 
function calls would be weird: in the above example, you wouldn't be 
able to call sin(5) as the compiler wouldn't be able to distinguish 
which function is called.

renoX

> 
> That true.
> 
> Regan