Do we really need const?

Regan Heath regan at netmail.co.nz
Tue Sep 18 03:25:15 PDT 2007


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.

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 diplay the 
source in another form (printed or something) you loose the information 
again.

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.

 > 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++.

That true.

Regan



More information about the Digitalmars-d mailing list