www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4734] New: immutable return type specifier without parantheses confuses the compiler

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4734

           Summary: immutable return type specifier without parantheses
                    confuses the compiler
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: andrej.mitrovich gmail.com


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2010-08-26
14:15:31 PDT ---
import std.stdio;

class Test
{
    immutable char foo()
    {
        return 'z';
    }
}

unittest
{
    auto test = new Test;
    test.foo();
}

void main()
{
}

error:
test2.d(16): Error: function test2.Test.foo () immutable is not callable using
argument types ()

Note that using const instead of immutable works.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 26 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4734


Jonathan M Davis <jmdavisProg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmail.com


--- Comment #1 from Jonathan M Davis <jmdavisProg 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: -------
Aug 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4734



--- Comment #2 from Andrej Mitrovic <andrej.mitrovich 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: -------
Aug 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4734


Stephan Dilly <spam extrawurst.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |spam extrawurst.org


--- Comment #3 from Stephan Dilly <spam 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: -------
Aug 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4734


Stephan Dilly <spam extrawurst.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement


--- Comment #4 from Stephan Dilly <spam 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: -------
Aug 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4734



--- Comment #5 from Jonathan M Davis <jmdavisProg 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: -------
Aug 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4734



--- Comment #6 from Andrej Mitrovic <andrej.mitrovich 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: -------
Oct 04 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4734



--- Comment #7 from Andrej Mitrovic <andrej.mitrovich 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: -------
Sep 17 2013