June 06, 2013
What would be good is:

@property int foo {
    get() {
        _val = value;
    }
    set() {
        value = _val;
    }
}

usage:

foo = 12;
int bar = foo;


my 2 cents.
June 06, 2013
On Thursday, 6 June 2013 at 10:38:27 UTC, Martin Primer wrote:
> What would be good is:
>
> @property int foo {
>     get() {
>         _val = value;
>     }
>     set() {
>         value = _val;
>     }
> }
>
> usage:
>
> foo = 12;
> int bar = foo;
>
>
> my 2 cents.

That's both much more limited and longer than the current syntax. It also turns properties from a simple rewrite rule into a full language feature, and it doesn't seem to give any benefits?
June 06, 2013
On Wednesday, 5 June 2013 at 22:25:21 UTC, Adam D. Ruppe wrote:
> 3) prop += 5 and friends

This is the biggest deal for me. Being able to write all these read-modify-write operators on properties would simplify writing transparent wrapper types so much.
June 06, 2013
On Wed, 05 Jun 2013 17:36:11 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> Strict property enforcement is as good as dead. -property is still there for
> the moment, but its days are numbered. Walter and Andrei pretty much consider
> @property to have been a failure and seem to want to get rid of @property and
> go to pretty much what we had before. _Exactly_ what we're going to end up
> with isn't clear at the moment, but it's crystal clear that strict property
> enforcement will never happen, because it's too unpopular.

I think any solution has to disallow setter syntax on arbitrary functions.

Anything else is up for debate IMO.  And I've come to the point where I don't care, as long as SOMETHING is decided.

One other sticky point is UFCS properties.

-Steve
June 06, 2013
On Wednesday, 5 June 2013 at 18:09:30 UTC, Gary Willoughby wrote:
> I've been using the -property compiler flag when i compile programs and thought it was pretty cool but i've recently had a conversation with someone who has informed me it's broken and a bad idea.
>
>> Never, ever, ever use -property. Its implementation is totally wrong
>> and based on a flawed idea to begin with. Using it just breaks good
>> code and gives nothing in return. From the ng discussions looks like
>> I'm going to get my way soon and it will be removed and buried like it
>> deserves. If you remove that, everything else works.
>
> Can someone point me to the discussion on this or quickly fill me in as to why this is the case. I have no opinion on the subject as i'm ignorant of this topic.
>
> Thanks.

It is useful as "get that ruby out of my code" warning ;)
1 2 3
Next ›   Last »