On 2011-04-08 15:54, Michel Fortin wrote:
> > I don't know what dmd fixes you did, but I believe there are several bugs relating to @property which make it so that some things with properties would become impossible. One issue which is going to require either a change in dmd or Phobos is http://d.puremagic.com/issues/show_bug.cgi?id=5707 . There are several functions in std.file which make perfect sense as properties when they take strings but don't make as much sense as properties when they take an int (and _can't_ be properties without UFCS). Functions such as isFile and isDir either take a string which holds a path or a uint which holds the attributes of a file. The compiler currently enforces that a property function is a property function for all of its overloads and that doesn't work in this case. I don't know why that restriction is in place (possibly because the compiler deals with property syntax _before overload resolution?), but it's a problem for std.file which makes it so that either those functions can't be properties, the attribute version must be renamed, or dmd has to be fixed.
> 
> 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.

- Jonathan M Davis

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/

> 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.

I don't see why that's a syntactic mess. In the one case, it takes a string and is a property function. In the other, it takes an int and is not a property function. The property function is called as a property and the non- property function is called as a normal function. It seems to me that it should work just fine and that UFCS has nothing to do with it. UFCS definitely enters in if they're both property functions, since then you'd have to do 9.isDir (which is hideous IMHO), but arrays work just fine with member function call syntax (or whatever it's called for just arrays) and properties. I see no ambiguity here at all.

- Jonathan M Davis