On 2013-01-31 18:08, Andrei Alexandrescu wrote:

> We use JITting right now:
> https://www.facebook.com/note.php?note_id=10150415177928920

Aha, I didn't know that.

-- 
/Jacob Carlborg

On Thursday, 31 January 2013 at 15:40:19 UTC, Michel Fortin wrote:
> On 2013-01-31 14:50:40 +0000, "Steven Schveighoffer" <schveiguy@yahoo.com> said:
>
>> It actually is a bit depressing, we have to reset the clock back to late  2009 to start over with properties...
>
> I haven't participated in the discussions about properties this time around because it's pretty obvious to me it's getting nowhere.
>
> It seems to me that nothing can be done at this point in time if we want to avoid a breakage of almost all current D code.

Also if you're worried about the code breakage necessary  to get properties as structs, i.e. nested structs must now have "static" in front of them, consider:

1) That having structs which are nested inside functions hold a pointer without having structs nested in structs do the same thing is an inconsistent language feature.

2) Second, that such struct will still work in all cases where an outer name is not being shadowed. They will simply suffer performance costs of having a needless pointer attached.

Also, is it really asking people too much to tag nested structs with "static" now?

On Thu, 31 Jan 2013 14:13:02 -0500, Zach the Mystic <reachBUTMINUSTHISzach@googlymail.com> wrote:

> On Thursday, 31 January 2013 at 15:40:19 UTC, Michel Fortin wrote:
>> And you have to admit that the way D does properties today is both simple, clever, and appealing. It does have some error-prone liabilities when it comes to callable types and generic programming especially, but beside that I do like the design of the thing. It's a natural extension of UFCS, even though it predates UFCS. Perhaps we should just call it a day and live with the ambiguities. I don't like it, but I don't see any viable alternative.
>
> I'm hoping that the community won't close the books on this issue without even *examining* my proposal, found here:
>
> http://forum.dlang.org/thread/kdukid$stg$1@digitalmars.com?page=2#post-yqvrjszzlcpmmuyqyxdz:40forum.dlang.org

I looked at it, it seems extremely similar to C# properties, which has been proposed before.

Not that there's anything wrong with it, I'm saying it's a duplicate of what has been proposed.  If it were to be an acceptable solution, I'd be on board (though I don't know why we wouldn't use the same notation as C# for familiarity).

Don't hold your breath waiting for Walter to respond though, he is notoriously silent unless he completely disagrees with you.

-Steve

Static nested struct as property... what is going on...
In this case is better to simply rid-off @property keyword.

"Properties" are better implemented where they created. Maybe have bugs in design, but I think that property should be a simple access method/function without struct-and-whatever-else kung-fu code.

On 2013-01-31 15:57:12 +0000, "Steven Schveighoffer" <schveiguy@yahoo.com> said:

> [...]
> 
> Turns out, this translates to:
> 
> ts.seconds(5);
> 
> and because you can call static methods from an instance (another thing I  don't really like), it made the constructor act like a property!  A  completely unintended consequence.
> 
> The only viable solution (this was D1), was to rename the functions so  they couldn't be mistaken as properties.  So they all became "fromSeconds"  e.g.  Yuck!

Could also have used global functions instead of static ones inside of the class. I still see your point.


> At this point, I think it would be a huge step backwards not to solve (or  at least have a yet-to-be implemented solution for) the above problem.  I  can live with getters simply being parentheses-less functions, that isn't  so bad (though as an API designer, I'd like to have full control over  that).  But using any function as a setter is crap, and will forever be a  wart on D unless we fix it.  It will result in bizarre things like mystery  setters that don't exist, especially with UFCS.

True.

Still, Walter has shown no sign he's willing to accept any solution that won't work with most of current code. Just look at his syntax proposal in the thread "take it behind the woodshed and shoot it?" if you're not convinced. At the same time he has gone to great lengths to keep things backward compatible even with experimental syntaxes (I'm thinking of user defined attributes). I seriously doubt changing the syntax for setters will happen… unless you can make it backward compatible.

As for keeping the syntax backward compatible, you could for instance propose an attribute to prevent people from using the setter syntax when calling a particular function:

	@explicit TimeDuration seconds(float);


-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

On Thursday, 31 January 2013 at 19:13:03 UTC, Zach the Mystic wrote:
> I'm hoping that the community won't close the books on this issue without even *examining* my proposal, found here:
>
> http://forum.dlang.org/thread/kdukid$stg$1@digitalmars.com?page=2#post-yqvrjszzlcpmmuyqyxdz:40forum.dlang.org


I'm just going to repeat the arguments I've already made on the "Property discussion wrap-up" thread against the idea of using a variable as a property:

struct MyArray
{
    int _len;

    // struct2.0 variables have an implicit reference 'outer' to
    // the enclosing object (don't ask how... not my idea)

    struct2.0 Len
    {
        int opCall() const
        {
            return outer._len;
        }

        alias this = opCall;

        void opAssign(int v) const
        {
            outer._len = v;
        }
    }

    Len length; // please ignore the memory overhead over here
}

void func(N)(N n)
    if (isConvertible!(N,int))
{
    n = 123;
}

void main()
{
    MyArray arr;
    func(arr.length); // changes arr._len (not good)
}

On 2013-01-31 19:13:02 +0000, "Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> said:

> Or just shut me up by saying something about why it's just wrong or simply can't work.

Don't take it personally. I'm not saying anything about your proposal, or any other proposal for that matter. All I'm saying is that I find it very unlikely that this discussion changes anything. Sorry for being pessimistic.

I'm not the one you need to convince, Walter decides in the end. And he has shown little inclination to make changes to how properties works other than some subtle refinements. This was true in 2009, it seems to be even more the case today.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

On Thursday, 31 January 2013 at 20:52:39 UTC, Steven Schveighoffer wrote:
>> I'm hoping that the community won't close the books on this issue without even *examining* my proposal, found here:
>>
>> http://forum.dlang.org/thread/kdukid$stg$1@digitalmars.com?page=2#post-yqvrjszzlcpmmuyqyxdz:40forum.dlang.org
>
> I looked at it, it seems extremely similar to C# properties, which has been proposed before.
>
> Not that there's anything wrong with it, I'm saying it's a duplicate of what has been proposed.  If it were to be an acceptable solution, I'd be on board (though I don't know why we wouldn't use the same notation as C# for familiarity).
>
> Don't hold your breath waiting for Walter to respond though, he is notoriously silent unless he completely disagrees with you.
>
> -Steve

Thanks for looking at it.

I only read the C# documentation for properties briefly, but I didn't find my suggestion to be a duplicate of them. In particular, can C# properties do anything more than just get and set? My suggestion allows harnessing the full power of D struct semantics. Is this not a far more expansive solution than what C# has?

My opGet is just another opXXX definable for all structs, not just properties. I had said it was necessary to achieve structs as properties, but I think I was wrong. It's just the equivalent of:

int __someRandomFunction() { return _propValue; }
alias __someRandomFunction this;

But it would be syntactically nicer, much like Highlander structs are syntactically nicer. Therefore, the only language change absolutely required would be making non-static structs nested in structs behave like non-static structs nested in functions, which they arguably should do anyway. Also under the hood, some important optimizations getting rid of pointers for data-less structs.

You know, the words "opGet" and "opAssign" (and all the other opXXX's) are rather ugly, but I guess anyone who has defined them in the past could come to love them, for their power if not for their looks.

On Thursday, 31 January 2013 at 19:13:03 UTC, Zach the Mystic wrote:
> I'm hoping that the community won't close the books on this issue without even *examining* my proposal, found here:
>
> http://forum.dlang.org/thread/kdukid$stg$1@digitalmars.com?page=2#post-yqvrjszzlcpmmuyqyxdz:40forum.dlang.org

I don't think the community is ready to close the books on this.

I got to D before C#, two things that bothered with C# was Events and Properties. And that was purely at the syntactic level. And have a similar issue with Java's introduction of foreach. Why does it have to be so hard to remember the syntax of these very simple constructs!

Anyway, I don't see what your plan offers from just fixing @property to do what is needed. I've also got overwhelmed by the complexity to writing properties.

On Thu, 31 Jan 2013 17:11:28 -0500, Zach the Mystic <reachBUTMINUSTHISzach@googlymail.com> wrote:

> Thanks for looking at it.
>
> I only read the C# documentation for properties briefly, but I didn't find my suggestion to be a duplicate of them. In particular, can C# properties do anything more than just get and set? My suggestion allows harnessing the full power of D struct semantics. Is this not a far more expansive solution than what C# has?

C# has properties like this:

property int foo {
  get {return _foo;}
  set {_foo = value;}
}

Your proposal looks like this:

foo struct {
   int opGet() {return _foo;}
   void opSet(int value) {_foo = value;}
}

What I see is that the getter and setter are assigned specific contextual keywords (opGet vs. get, and opSet vs. set). It seems like a very similar (albeit more verbose) solution.

What I had originally suggested for properties is this:

property int foo {
   int get() {return _foo;} // only one getter allowed
   void set(int v) {_foo = v;}
   void set(float v) {_foo = (int)v;} // more than one setter allowed
}

I think these are all along the same line of solutions.  I don't think they are bad, but clearly they weren't used 4 years ago, so it may be difficult to convince Walter to use them now.

> My opGet is just another opXXX definable for all structs, not just properties.

I didn't see that, but I also don't really see the point of that.  What value does opGet have unless it's a getter for a property?

> I had said it was necessary to achieve structs as properties, but I think I was wrong. It's just the equivalent of:
>
> int __someRandomFunction() { return _propValue; }
> alias __someRandomFunction this;
>
> But it would be syntactically nicer, much like Highlander structs are syntactically nicer. Therefore, the only language change absolutely required would be making non-static structs nested in structs behave like non-static structs nested in functions, which they arguably should do anyway. Also under the hood, some important optimizations getting rid of pointers for data-less structs.

This is a VERY bad idea.  A struct is POD.  For example, consider a range type for a container.  You may not NEED to have a pointer to the container, so that is wasted bytes.

Also note that structs are not meant to have internal pointers.  So a "property" struct with an internal pointer

The strange case for a struct type inside a function kind of makes sense, because of the ability to access the function's variables, and because you can't really move the stack frame.

-Steve