[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=4734

Andrej Mitrovic  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #8 from Andrej Mitrovic  ---
(In reply to Andrej Mitrovic from comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > In any case, at minimum, the error message needs to be improved.
> > 
> > How about we implement these error messages like this:
> > 
> > Error: function test.Test.foo () const is not callable using (this)
> > Error: function test.Test.foo () is not callable using const(this)
> > 
> > It's a little bit more informative than just a lone set of parens.
> 
> P.S. this is now:
> Error: immutable method test.Test.foo is not callable using a mutable object
> 
> I'm thinking of closing this, since the diagnostic is informative enough to
> know what went wrong.

Marking as resolved for this reason.

--

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734



--- Comment #7 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-17 
12:58:02 PDT ---
(In reply to comment #6)
 (In reply to comment #5)
  In any case, at minimum, the error message needs to be improved.
 
 How about we implement these error messages like this:
 
 Error: function test.Test.foo () const is not callable using (this)
 Error: function test.Test.foo () is not callable using const(this)
 
 It's a little bit more informative than just a lone set of parens.

P.S. this is now:
Error: immutable method test.Test.foo is not callable using a mutable object

I'm thinking of closing this, since the diagnostic is informative enough to
know what went wrong.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734



--- Comment #6 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-04 
16:15:50 PDT ---
(In reply to comment #5)
 In any case, at minimum, the error message needs to be improved.

How about we implement these error messages like this:

Error: function test.Test.foo () const is not callable using (this)
Error: function test.Test.foo () is not callable using const(this)

It's a little bit more informative than just a lone set of parens.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734


Jonathan M Davis jmdavisp...@gmail.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmail.com


--- Comment #1 from Jonathan M Davis jmdavisp...@gmail.com 2010-08-26 
14:44:23 PDT ---
Unfortunately, this is not a bug. Putting either const or immutable on a
function - be it on the left of the function signature or the right - makes
that function immutable. If you want the return type to be const or immutable,
you _must_ use parens. As I understand it, this was done to make const and
immutable work the sames as modifiers like private, public, pure, and nothrow
(which mean the same thing regardless of which side of the function that
they're on). A number of use would like const and immutable to have to be on
the right if you want to make the function const or immutable, but Walter
doesn't agree, so it doesn't work that way.

So, your function declaration is making the function immutable, _not_ the
return type. The reason why using const with your unit test works but immutable
does not is because both mutable and immutable values can be used with const
functions, but only immutable ones can be used with immutable functions.

immutable test = new Test;
test.foo();

should work just fine with the way that you declared the function. Now, I think
that the error message definitely needs some work; it should indicate that the
variable needs to be immutable rather than talking about the function arguments
(it's probably doing that because the this pointer is an invisible function
argument), but it is essentially correct.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734



--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-08-26 
14:53:11 PDT ---
You are absolutely right. I forgot about the ability to make functions
themselves const/immutable. It would really help if that right-side rule was in
place, because all this will do right now is cause confusion (unless we get a
nicer error message, in which case we can keep the flexibility I think..).

So maybe I should change this to an enhancement request for a better error
message.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734


Stephan Dilly s...@extrawurst.org changed:

   What|Removed |Added

 CC||s...@extrawurst.org


--- Comment #3 from Stephan Dilly s...@extrawurst.org 2010-08-26 15:14:48 PDT 
---
(In reply to comment #2)
 You are absolutely right. I forgot about the ability to make functions
 themselves const/immutable. It would really help if that right-side rule was 
 in
 place, because all this will do right now is cause confusion (unless we get a
 nicer error message, in which case we can keep the flexibility I think..).
 
 So maybe I should change this to an enhancement request for a better error
 message.

I disagree, just like any other storage class the current annotating enables
the user to group blocks of methods with equivalent storage classes like this:

class Foo{
static{
void foo();
}

const{
const(ConstReturnVal) bar();
}
}

it is nothing but consistent and should stay as it is.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734


Stephan Dilly s...@extrawurst.org changed:

   What|Removed |Added

   Severity|normal  |enhancement


--- Comment #4 from Stephan Dilly s...@extrawurst.org 2010-08-26 15:16:58 PDT 
---
(In reply to comment #3)
 (In reply to comment #2)
  You are absolutely right. I forgot about the ability to make functions
  themselves const/immutable. It would really help if that right-side rule 
  was in
  place, because all this will do right now is cause confusion (unless we get 
  a
  nicer error message, in which case we can keep the flexibility I think..).
  
  So maybe I should change this to an enhancement request for a better error
  message.
 
 it is nothing but consistent and should stay as it is.

sorry i should have read to the end. i aggree that the error message could be
improved ;)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734



--- Comment #5 from Jonathan M Davis jmdavisp...@gmail.com 2010-08-26 
15:47:47 PDT ---
The error message definitely needs to be improved. However, if you're arguing
for consistency, you could easily argue that the current way is not consistent
because it's not consistent with variable declarations. If I declare

const T foo;

then foo is going to be a const T. However, if I declare

const T foo() {}

then now T is not const. Rather the object that foo is a member of is const.
So, the current situation is _not_ completely consistent. It chooses to be
consistent with one feature and not another because it can't be consistent with
both. However, anyone coming from a C++ background will expect that function
declaration to return a const T and that you would have to put the const to the
right of the function name to make it const. This topic has come up a number of
times, and there are quite a few folks who think that the current situation is
flawed. There's certainly no question that it's confusing. Personally, I'd
argue that function modifiers should just go on the right of the function,
except that that would be confusing with regards to modifiers like private or
abstract which other languages put to the left of the function.

So, I'd strongly argue that it will cause fewer problems if you had to put
immutable and const to the right of the function name to make the function
immutable or const. Yes, it's inconsistent with other function modifiers, but
it's more consistent with variable declarations and other languages., and it
will causes less confusion. The other solution would be to always require
parens for const and immutable types regardless of whether they're for return
types or variable declarations, but I can't imagine that that would go over
very well.

In any case, at minimum, the error message needs to be improved.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---