Le 2011-04-21 ? 13:09, Walter Bright a ?crit :

> On 4/21/2011 6:24 AM, Michel Fortin wrote:
>> I'm just wondering how many DMD release will pass before my "const(Object)ref" pull request for DMD get reviewed. I don't want to push Walter too much, but the more he waits the more likely it won't merge so easily.
> 
> I understand. My current priority is to get temp destruction to work right. Following on is fixing fundamental issues with const, and getting disabling of default construction to work.

Thanks for letting us know of the roadmap.

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

Le 2011-04-21 ? 13:45, Jonathan M Davis a ?crit :

> TDPL specifically gives it strict semantics. @property functions must be called without parens, and non- at property functions must be called with them. So, if we want to go with loose semantics, then TDPL will need to be changed.
> 
> Personally, I don't see much point to @property if its semantics are loose.

Me neither: if the semantics are loose @property serves no purpose.

But there's still a big problem: the semantics of @property are quite ambiguous when it comes to the array member syntax. Something needs to be done about that before @property can be enforced properly.

I think having a @property-enforced mode, which could stay experimental for a few releases (activated with a command-line switch), would help test and sort out many of those issues. I can make a pull request for that -- is that a good idea?

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

On Thu, 21 Apr 2011 13:45:09 -0400, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

>> As I've said before, we really need to decide whether @property has
>> loose
>> or strict semantics. Loose semantics means that non- at property functions
>> would still be callable without (), etc but @property functions wouldn't
>> be allowed to have ()s. Frankly, I hate @property, want to to have as
>> little effect as possible, like the flexibility of being able to call
>> the
>> same function both ways, and would have a lot of code break if this were
>> taken away, so my vote is loose semantics.
>
> TDPL specifically gives it strict semantics. @property functions must be
> called without parens, and non- at property functions must be called with
> them.
> So, if we want to go with loose semantics, then TDPL will need to be
> changed.
>
> Personally, I don't see much point to @property if its semantics are loose.
>
> - Jonathan M Davis

The point of @property, and the reason it was included in the language at all, was to provide property syntax to the corner case of a returning a zero-argument delegate from a function. That's all. That was the only argument which was considered strong enough out of the many forum discussions to warrant language status. Furthermore, @property was explicitly defined at the time as having loose semantics. Regarding TDPL, Andrei has expressed serious concerns with going whole-hog @property since getting more experience with actually using it, so I don't feel that TDPL is a strong guideline.

My point is that a strict interpretation of @property has not seriously been discussed in the D community, and that any decision made here needs to be elevated to the D newsgroup before implementation.

My position comes down on the side of loose semantics with no method of strict enforcement, optional or otherwise.

Le 2011-04-21 ? 14:00, Robert Jacques a ?crit :

> On Thu, 21 Apr 2011 09:24:39 -0400, Michel Fortin <michel.fortin at michelf.com> wrote:
> 
>> Le 2011-04-21 ? 6:48, Torarin a ?crit :
>> 
>>> Dmd has a bug that causes the @property attribute to be disregarded in functions that return auto.
>> 
>> Indeed. I think I have a fix for that in the "@property" branch of my DMD fork on github. Perhaps I should make a pull request from that.
>> 
>> Actually, I could make a pull request for the entire "@property" branch, it shouldn't impact things much as enforcement of @property is only done if you add the command line switch -property. Would that make sense?
> 
> Michel, does your patch also include fixes/additions to __traits and std.traits

No. It just adds @property enforcement and fix two issues with auto return types so that I could make druntime and most of Phobos compile. Look at those five commits:
<https://github.com/michelf/dmd/compare/fb2a0...%40property>

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

> Le 2011-04-21 ? 13:45, Jonathan M Davis a ?crit :
> > TDPL specifically gives it strict semantics. @property functions must be called without parens, and non- at property functions must be called with them. So, if we want to go with loose semantics, then TDPL will need to be changed.
> > 
> > Personally, I don't see much point to @property if its semantics are loose.
> 
> Me neither: if the semantics are loose @property serves no purpose.
> 
> But there's still a big problem: the semantics of @property are quite ambiguous when it comes to the array member syntax. Something needs to be done about that before @property can be enforced properly.
> 
> I think having a @property-enforced mode, which could stay experimental for a few releases (activated with a command-line switch), would help test and sort out many of those issues. I can make a pull request for that -- is that a good idea?

Sounds good to me, though I know that there are some functions std.file which will become uncallable with strict enforcement due to the fact that property functions cannot currently be overridden with non-property functions, and some functions which should be property functions for strings and non-property functions for ints are currently properties for both, and you can't call a property function on an int. As long as code isn't calling those functions though, they won't pose a problem, and we can find plenty of other issues using the flag.

- Jonathan M Davis

> On Thu, 21 Apr 2011 13:45:09 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> >> As I've said before, we really need to decide whether @property has
> >> loose
> >> or strict semantics. Loose semantics means that non- at property functions
> >> would still be callable without (), etc but @property functions wouldn't
> >> be allowed to have ()s. Frankly, I hate @property, want to to have as
> >> little effect as possible, like the flexibility of being able to call
> >> the
> >> same function both ways, and would have a lot of code break if this were
> >> taken away, so my vote is loose semantics.
> > 
> > TDPL specifically gives it strict semantics. @property functions must be
> > called without parens, and non- at property functions must be called with
> > them.
> > So, if we want to go with loose semantics, then TDPL will need to be
> > changed.
> > 
> > Personally, I don't see much point to @property if its semantics are loose.
> > 
> > - Jonathan M Davis
> 
> The point of @property, and the reason it was included in the language at all, was to provide property syntax to the corner case of a returning a zero-argument delegate from a function. That's all. That was the only argument which was considered strong enough out of the many forum discussions to warrant language status. Furthermore, @property was explicitly defined at the time as having loose semantics. Regarding TDPL, Andrei has expressed serious concerns with going whole-hog @property since getting more experience with actually using it, so I don't feel that TDPL is a strong guideline.
> 
> My point is that a strict interpretation of @property has not seriously been discussed in the D community, and that any decision made here needs to be elevated to the D newsgroup before implementation.
> 
> My position comes down on the side of loose semantics with no method of strict enforcement, optional or otherwise.

I know that there are a number of people on the list - particularly newer posters - who fully expect @property to be strict and are surpised when it isn't. And I see _zero_ problem with strong property enforcement as long as the compiler isn't buggy with regards to properties (which it currently is). So, I'm 100% behind strict enforcement.

- Jonathan M Davis

How about the amount of existing code it breaks?  How about the fact that it breaks using the same function for both method chaining and with property syntax?

On Thu, Apr 21, 2011 at 3:39 PM, Jonathan M Davis <jmdavisProg at gmx.com>wrote:

> > On Thu, 21 Apr 2011 13:45:09 -0400, Jonathan M Davis <
> jmdavisProg at gmx.com>
> >
> > wrote:
> > >> As I've said before, we really need to decide whether @property has
> > >> loose
> > >> or strict semantics. Loose semantics means that non- at propertyfunctions
> > >> would still be callable without (), etc but @property functions
> wouldn't
> > >> be allowed to have ()s. Frankly, I hate @property, want to to have as
> > >> little effect as possible, like the flexibility of being able to call
> > >> the
> > >> same function both ways, and would have a lot of code break if this
> were
> > >> taken away, so my vote is loose semantics.
> > >
> > > TDPL specifically gives it strict semantics. @property functions must
> be
> > > called without parens, and non- at property functions must be called with
> > > them.
> > > So, if we want to go with loose semantics, then TDPL will need to be
> > > changed.
> > >
> > > Personally, I don't see much point to @property if its semantics are loose.
> > >
> > > - Jonathan M Davis
> >
> > The point of @property, and the reason it was included in the language at all, was to provide property syntax to the corner case of a returning a zero-argument delegate from a function. That's all. That was the only argument which was considered strong enough out of the many forum discussions to warrant language status. Furthermore, @property was explicitly defined at the time as having loose semantics. Regarding TDPL, Andrei has expressed serious concerns with going whole-hog @property
> since
> > getting more experience with actually using it, so I don't feel that TDPL is a strong guideline.
> >
> > My point is that a strict interpretation of @property has not seriously been discussed in the D community, and that any decision made here needs to be elevated to the D newsgroup before implementation.
> >
> > My position comes down on the side of loose semantics with no method of strict enforcement, optional or otherwise.
>
> I know that there are a number of people on the list - particularly newer
> posters - who fully expect @property to be strict and are surpised when it
> isn't. And I see _zero_ problem with strong property enforcement as long as
> the compiler isn't buggy with regards to properties (which it currently
> is).
> So, I'm 100% behind strict enforcement.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110421/2821d730/attachment.html>

On Thu, 21 Apr 2011 15:19:26 -0400, Michel Fortin <michel.fortin at michelf.com> wrote:

> Le 2011-04-21 ? 14:00, Robert Jacques a ?crit :
>
>> On Thu, 21 Apr 2011 09:24:39 -0400, Michel Fortin <michel.fortin at michelf.com> wrote:
>>
>>> Le 2011-04-21 ? 6:48, Torarin a ?crit :
>>>
>>>> Dmd has a bug that causes the @property attribute to be disregarded in functions that return auto.
>>>
>>> Indeed. I think I have a fix for that in the "@property" branch of my DMD fork on github. Perhaps I should make a pull request from that.
>>>
>>> Actually, I could make a pull request for the entire "@property" branch, it shouldn't impact things much as enforcement of @property is only done if you add the command line switch -property. Would that make sense?
>>
>> Michel, does your patch also include fixes/additions to __traits and std.traits
>
> No. It just adds @property enforcement and fix two issues with auto return types so that I could make druntime and most of Phobos compile. Look at those five commits: <https://github.com/michelf/dmd/compare/fb2a0...%40property>
>

Understood. I'd recommend adding something like __traits(isProperty, C.bar) to the todo list though.

2011/4/21 Michel Fortin <michel.fortin at michelf.com>: [...]
> No. It just adds @property enforcement and fix two issues with auto return types so that I could make druntime and most of Phobos compile. Look at those five commits:
> <https://github.com/michelf/dmd/compare/fb2a0...%40property>
>
> --
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/

This indeed fixes typeof on @property functions that return auto.

Torarin

> How about the amount of existing code it breaks?  How about the fact that it breaks using the same function for both method chaining and with property syntax?

Something like

auto b = a.prop1.prop2.prop3;

should work. I doesn't at present, but it should. There's a bug report on it. As for breaking existing code, _of course_ it's going to. That's to be expected, and I would have thought that that was expected when @property was introduced in the first place. It just hasn't happened yet because @property has been introduced in steps. First it's added but not enforced. Then, once it works properly, we can make the change to enforcement like any other breaking change: first warning about it, then deprecating it, and then outright making it an error.

I don't think that there's much question that @property can't currently be enforced - there are too many @property bugs - and we're going to have make the switch in stages just like any other breaking change. But I don't think that that's reason enough to not go for strict enforcement. I definitely think that @property is essentially pointless without strict enforcement.

- Jonathan M Davis