[Bug c++/56004] New: Possible bug with decltype and access modifer order

[Bug c++/56004] New: Possible bug with decltype and access modifer order

[david.irvine at maidsafe dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004

             Bug #: 56004
           Summary: Possible bug with decltype and access modifer order
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: david.irvine@maidsafe.net


Please see this stackoverflow question for an overview.
http://stackoverflow.com/questions/14188535/clang-access-modifier-order-and-decltype

The issue seems to be that the private members are not visible at compilation
to the decltype call. This is a minimum example (from the question).  (I am the
questioner in this case). This also seems to appear as a 'bug' in gcc but not
msvc (12). I am not 100% convinced but cannot find in the standard why this
will not work. I hope this helps. 

#include <future>
#include <iostream>
#include <thread>
#include <vector>

template <class T> T &self(T &t) { return t;  }
template<typename T> struct Dependent {  };

template<typename T>
class Synchronised : Dependent<T>{
 public:
  explicit Synchronised(T t = T()) : t_(t) {}
  template<typename Functor>
  auto operator()(Functor functor) const ->decltype(functor(self(*this).t_)) {
  //auto operator()(Functor functor) const ->decltype(functor(this->t_)) {
    std::lock_guard<std::mutex> lock(mutex_);
    return functor(t_);
  }
 private:
  mutable T t_;
  mutable std::mutex mutex_;
};


int main() {

    Synchronised<std::string> sync_string("Start\n");
    std::vector<std::future<void>> futures;
}

[Bug c++/56004] Possible bug with decltype and access modifer order

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-01-16 16:19:33 UTC ---
As was explained on stackoverflow, this has nothing t odo with access
modifiers, as you can easily demonstrate by making everything public.

_t has not been declared at the point where you try to use it, so the name is
not in scope.  What are you claiming is a bug?

[Bug c++/56004] Possible bug with decltype and access modifer order

[david.irvine at maidsafe dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004

--- Comment #2 from David Irvine <david.irvine at maidsafe dot net> 2013-01-16 16:40:43 UTC ---
(In reply to comment #1)
> As was explained on stackoverflow, this has nothing t odo with access
> modifiers, as you can easily demonstrate by making everything public.
> 
> _t has not been declared at the point where you try to use it, so the name is
> not in scope.  What are you claiming is a bug?

It might be my confusion but is that not altering modifiers ? I am not sure why
the initialisation list does not make the private member available (at least
declared). 

On the clang mailing list this was hinted at as well, but I am not sure that
this is a case where private: before public: does work and not vice versa
although as I said it is very likely a c++ issue that I have just not come
across yet (although I will remember as usual).

Can you confirm why the _t is not available or declared when it is in the
initialisation list ? does the decltype require earlier visibility than the ctr
? 

Sorry if this is indeed not a bug but a misunderstanding.

[Bug c++/56004] Possible bug with decltype and access modifer order

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-01-16 17:30:55 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > As was explained on stackoverflow, this has nothing t odo with access
> > modifiers, as you can easily demonstrate by making everything public.
> > 
> > _t has not been declared at the point where you try to use it, so the name is
> > not in scope.  What are you claiming is a bug?
> 
> It might be my confusion but is that not altering modifiers ?

I don't know what you mean. Change "private" to "public", the code fails in
exactly the same way, therefore the problem is nothing to do with
accessibility.

> I am not sure why
> the initialisation list does not make the private member available (at least
> declared). 

The init list is a *use* of the member, not a declaration. Ctor init lists are
part of the function body, so only parsed once the class is complete.  You
could also use t_ in the constructor body, that doesn't mean it's in scope
outside that function body.


> On the clang mailing list this was hinted at as well, but I am not sure that
> this is a case where private: before public: does work and not vice versa
> although as I said it is very likely a c++ issue that I have just not come
> across yet (although I will remember as usual).

It has nothing to do with private vs public!

> Can you confirm why the _t is not available or declared when it is in the
> initialisation list ? does the decltype require earlier visibility than the ctr
> ? 

See above. The init list is part of a function body. Function bodies are
processed when the class is complete, as though they were defined after the
class. Look:

struct A {
    A() : i(0) { ++i; }  // i is in scope

    decltype(i) get();  // error, i not in scope

    int i;   // i declared here

    decltype(i) get2();  // OK, i has been declared
};

This is equivalent to:

struct A {
    A();

    decltype(i) get();  // error, i not in scope

    int i;   // i declared here

    decltype(i) get2();  // OK, i has been declared
};

A::A() : i(0) { ++i; }  // OK, class is complete, i in scope.


In the first example the constructor can use 'i' in the init list and the ctor
body, that's OK. You can *not* use 'i' in a function signature before it's
declared. get() is an error, get2() is OK.

[Bug c++/56004] Possible bug with decltype and access modifer order

[david.irvine at maidsafe dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004

--- Comment #4 from David Irvine <david.irvine at maidsafe dot net> 2013-01-16 18:16:58 UTC ---
I see

In my case in a simpler version than posted 

this compiles fine  

template <class T>
class Synchronised {
    public:
        Synchronised(T t = T{}) : t_{t} {}
        template <typename F>
        auto operator()(F f) const -> decltype(f(t_)) {
            std::lock_guard<std::mutex> lock{mutex_};
            return f(t_);
        }
        private: // place this before public: and this object compiles
            mutable T t_;
            mutable std::mutex mutex_;
};

Fails and swapping private to be declared before public works ! as below

This will not compile 

template <class T>
class Synchronised {
      private: // place this before public: and this object compiles
            mutable T t_;
            mutable std::mutex mutex_;

    public:
        Synchronised(T t = T{}) : t_{t} {}
        template <typename F>
        auto operator()(F f) const -> decltype(f(t_)) {
            std::lock_guard<std::mutex> lock{mutex_};
            return f(t_);
        }
  };

I think you are saying the same thing but this is what I mean by private coming
before public (changing accessors or their order). I think it is the only
situation I have encountered this.

[Bug c++/56004] Possible bug with decltype and access modifer order

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-01-16 18:25:52 UTC ---
(In reply to comment #4)
> I think you are saying the same thing but this is what I mean by private coming
> before public (changing accessors or their order). I think it is the only
> situation I have encountered this.

You still seem to have some weird mental model about public and private.

This has nothing to do with "public" or "private"

In your example t_ happens to be private, but that is completely irrelevant.

It only matters if it is declared before it is used. It can be declared public,
or declared private, or protected, it's irrelevant.

This doesn't work either, even though everything is public:

template <class T>
class Synchronised {

    public:
        Synchronised(T t = T{}) : t_{t} {}
        template <typename F>
        auto operator()(F f) const -> decltype(f(t_)) {
            return f(t_);
        }

    public:
            mutable T t_;
  };


Closing as not a bug.