Dechenjm / crack-language

Automatically exported from code.google.com/p/crack-language
Other
0 stars 0 forks source link

+= not permitted for composite types that are function arguments #133

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I have a composite type called Integer (it's what you think it is, a bignum).

I just tried to write a function like this:

void myfun(Integer r, Integer a) {
   r += a;
}

But crack complains that r is constant.

I don't object to r being constant, but += does not modify r, only the contents 
of r, and certainly doing that is not prohibited by r being constant in any 
other way in crack. For example r.data = something_new; is certainly permitted.

Original issue reported on code.google.com by goodwill...@googlemail.com on 31 Dec 2014 at 4:07

GoogleCodeExporter commented 9 years ago
Does Integer implement "oper +=" or just "oper +"?  Because this seems to work 
for me:

  class A { void oper +=(int i) { } }
  void f(A a) { a += 1; }
  f(A());

If it only implements "oper +" then you would indeed have a problem, because += 
falls through to r = r + a which is prohibited for a const variable.  (The 
reason why parameters are const is complicated)

Original comment by mind...@gmail.com on 31 Dec 2014 at 4:42

GoogleCodeExporter commented 9 years ago
Yes inside the Integer class, I define:

   Integer oper +=(Integer b);

I checked again to make sure I had this correct, and it still fails for me 
(note I am using crack-0.8).

Two possibilites:

Perhaps it only fails for composite types, like my Integer, and not for system 
types, like int.

P.S: I don't mind parameters being const. I have colleagues who insist that 
this is correct. I don't prefer it myself, but can live with it either way. 
Obviously reference parameters would be useful, but I see there is already a 
ticket for that.

Original comment by goodwill...@googlemail.com on 31 Dec 2014 at 5:35

GoogleCodeExporter commented 9 years ago
Yes, I can reproduce this in 0.8.  It appears to be fixed in 0.9 and in the 
head revision, though, so I'm closing this.

Original comment by mind...@gmail.com on 1 Jan 2015 at 5:21