Bug 8490 – Global property calls do not work with pointers
Status
RESOLVED
Resolution
INVALID
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-08-01T07:27:00Z
Last change time
2012-09-04T10:55:18Z
Keywords
rejects-valid
Assigned to
nobody
Creator
andrej.mitrovich
Comments
Comment #0 by andrej.mitrovich — 2012-08-01T07:27:27Z
struct Foo { }
@property bool isTrue(Foo foo) { return true; }
void main()
{
Foo[int] x = [1:Foo()];
if (auto foo = 1 in x) {
bool b = foo.isTrue;
}
}
test.d(10): Error: no property 'isTrue' for type 'Foo'
Comment #1 by andrej.mitrovich — 2012-08-29T06:34:28Z
This is related to pointers not just auto expressions:
struct Foo { }
@property bool isTrue(Foo foo) { return true; }
void main()
{
Foo* foo = new Foo;
bool b = foo.isTrue;
}
Comment #2 by art.08.09 — 2012-08-29T15:11:31Z
(In reply to comment #1)
> This is related to pointers not just auto expressions:
>
> struct Foo { }
> @property bool isTrue(Foo foo) { return true; }
>
> void main()
> {
> Foo* foo = new Foo;
> bool b = foo.isTrue;
> }
@property bool isTrue(ref Foo foo) { return true; }
should probably work, but the by-value version might be too dangerous to be allowed...
Comment #3 by andrej.mitrovich — 2012-08-29T15:44:48Z
Why dangerous? Normal method invocations work, so why shouldn't UFCS work?
Comment #4 by art.08.09 — 2012-08-29T16:29:36Z
(In reply to comment #3)
> Why dangerous? Normal method invocations work, so why shouldn't UFCS work?
Having methods (what UFCS emulates) which implicitly create a copy of the object and operate on that copy would be confusing. Both for the interface user and the creator. The latter will be forgetting about the 'ref' while the former will not expect 'o.whatever' to copy 'o' and call 'whatever' using that private copy. Both issues would be bug sources.
Not introducing unsound features is easier than later removing them...
Comment #5 by andrej.mitrovich — 2012-08-29T16:36:05Z
(In reply to comment #4)
> (In reply to comment #3)
> > Why dangerous? Normal method invocations work, so why shouldn't UFCS work?
>
> Having methods (what UFCS emulates) which implicitly create a copy of the
> object and operate on that copy would be confusing. Both for the interface user
> and the creator. The latter will be forgetting about the 'ref' while the former
> will not expect 'o.whatever' to copy 'o' and call 'whatever' using that private
> copy. Both issues would be bug sources.
>
> Not introducing unsound features is easier than later removing them...
Oh I see what's going on now, the pointer can't be passed because it would have to be dereferenced. I think this is invalid then, thanks.
Comment #6 by issues.dlang — 2012-09-04T10:55:18Z
> Having methods (what UFCS emulates) which implicitly create a copy of the
object and operate on that copy would be confusing.
This already happens with structs and UFCS in general. e.g.
struct S {}
auto func(S s, int i) {...}
s.func(5);
makes as copy. So, I don't see that as a problem at all.