On 2011-04-08 13:42, Michel Fortin wrote:
> I made an experiment last month: I changed an "#if 0" to "#if 1" in the compiler source, one that was meant to enable proper enforcement of the property syntax. Then I went on an fixed a things everywhere to make everything compile and work.
> 
> It turned out to be a colossal task to fix everything that needed fixing (a few things DMD but most problems coming from Phobos and Druntime), and after doing a lot of it I started working on other things and left the project untouched since then.
> 
> I'd have preferred to present something finished, but given that I'm not sure when I'll work on it again I though it might be a good idea to let someone else take over (if someone wants to). Even if no one works on it, it might be interesting as a way to see how many things have been relying on the non-enforcement of @property. You can look at the "@property" branch in my dmd, druntime and Phobos forks on github to see what was affected by this change:
> 
> DMD:
> <https://github.com/michelf/dmd/commits/%40property>
> 
> Druntime: <https://github.com/michelf/druntime/commits/%40property>
> 
> Phobos: <https://github.com/michelf/phobos/commits/%40property>
> 
> Status: Druntime changes should be complete, Phobos is incomplete and I think I was stuck on a compiler bug triggered by it when I stopped working on it last month, so there might be still a few things to fix in the compiler.

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.

I also recall there being a bug which required property functions which returned a ref to be called with parens in at least some cases, though I don't know what bug # it would be.

So, there are definitely some changes that need to be made in dmd before @property can be enforced, even if Phobos or druntime used them correctly (which it can't in some cases). So, if you fixed them, that's great. If not, whoever keeps on with the work still has quite a bit of work to do.

Regardless, the fact that we use properties as much as we do in Phobos should definitely help in making sure dmd works correctly with @property.

- Jonathan M Davis

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


> I also recall there being a bug which required property functions which returned a ref to be called with parens in at least some cases, though I don't know what bug # it would be.
> 
> So, there are definitely some changes that need to be made in dmd before @property can be enforced, even if Phobos or druntime used them correctly (which it can't in some cases). So, if you fixed them, that's great. If not, whoever keeps on with the work still has quite a bit of work to do.
> 
> Regardless, the fact that we use properties as much as we do in Phobos should definitely help in making sure dmd works correctly with @property.

I might have fixed a few of those DMD bugs while doing all this. I gave myself the broad goal to "make @property work". I made it an error in DMD to call functions with the wrong syntax depending on whether they are @properties or not, and then I went to fix all the errors found when compiling Druntime and Phobos and their unit tests. Whenever I encountered something blocking, I fixed the problem at the source, in the compiler.

These two commits fix things related to @properties and auto returns:

Fixed an issue where @property was lost for functions with deduced return type. <https://github.com/michelf/dmd/commit/2ae23a0de72e56c6ec6ba9cd96de16e0140aa73d>

Fixed auto return function with postfix attributes. <https://github.com/michelf/dmd/commit/247a40a07a153768bd5c5f2694c3814496aec5e3>

And with this working I went on.

If someone wants to cherry-pick these two commits and apply them to DMD immediately, it might be a good idea.

In fact, now that I think about it, all the DMD commits could probably be merged given that property enforcement is optional (requires the -property command line switch).

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/