[phobos] The @property experiment

[Michel Fortin]

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
michel.fortin at michelf.com
http://michelf.com/