Le 2011-04-08 à 19:34, Jonathan M Davis a écrit :
> On 2011-04-08 15:54, Michel Fortin wrote:
>> You can't overload properties and non-properties today; changing whether
>> @property is enforced or not doesn't affect that. Fixing this problem is
>> entirely orthogonal. Whether it can be fixed is unclear however
>> considering that a property can return a delegate or another callable type
>> which would make things ambiguous.
>
> The problem is that isFile, isDir, etc. are currently marked as @property,
> because they should be properties when they take a string, but because you
> can't overload property functions with non-property functions, the uint
> versions are also marked with @property. As long as @property isn't enforced,
> you can continue calling the uint versions as normal functions, but once it's
> enforced, they become completely uncallable, because UFCS would be required
> to call them. So, either the compiler needs to be fixed so that the uint
> versions don't have to be property functions for the string versions to be
> property functions, or some or all of those functions in std.file need to be
> changed. I would much prefer that the compiler be changed, but regardless of
> which solution we should go with, a change _must_ be made before @property is
> enforced.
Well, it's not much of a problem as long as enforcing property is optional (via
a compiler switch) and not the default. But I agree with you; I think I
misunderstood what you meant in your previous message and I agree that there is
a problem.
It's the problem that was discussed at length on the forum a little while ago
and I'm not sure there was a clear solution. The problem being that UFCS (for
arrays) and @property don't mix well.
bool isDir(string str) @property;
isDir = "hello";
"hello".isDir;
Here, the property can be a setter and a getter at the same time! I did not try
to solve that issue. The changes I made doesn't disallow the above. So that's
the first problem. The second one is that you want to overload it with this:
bool isDir(int attr);
isDir(9);
Now we're in a real syntactic mess.
What we need is a way for the compiler to tell if a property is meant for UFCS
or not. UFCS-only properties would be safe to overload with global-scope
functions of the same name (because they wouldn't use the property syntax when
called at global scope), so it'd solve both problems. But there's no way to
tell apart UFCS properties from global-scope properties...
--
Michel Fortin
[email protected]
http://michelf.com/
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
