July 27, 2009
Sergey Gromov wrote:
> Fri, 24 Jul 2009 16:58:50 -0500, Andrei Alexandrescu wrote:
> 
>>>>> deterministic destructors,  arbitrary copy constructors, and optional
>>>>> lack of default constructor.
>>>> Struct have that except for default constructor. In D, currently default
>>>> constructors cannot execute code. This is a limitation that we might
>>>> need to address, although it has some advantages.
>>> There are things that copy constructors can do that the post-blit
>>> operator can't do.
>> Yes, mostly wrong things. I think it would be a huge loss if D copied C++'s model.
> 
> This means that structs cannot hold on external resources, ever:
> 
>     struct RAII {...}
>     var a = RAII("foo");
>     var b = RAII("bar");
>     a = b; // you just leaked a and corrupted b

You may be making a confusion between assignment and copy construction.

Andrei
July 27, 2009
Sun, 26 Jul 2009 21:23:35 -0500, Andrei Alexandrescu wrote:

> Sergey Gromov wrote:
>> Fri, 24 Jul 2009 16:58:50 -0500, Andrei Alexandrescu wrote:
>> 
>>>>>> deterministic destructors,  arbitrary copy constructors, and optional lack of default constructor.
>>>>> Struct have that except for default constructor. In D, currently default constructors cannot execute code. This is a limitation that we might need to address, although it has some advantages.
>>>> There are things that copy constructors can do that the post-blit operator can't do.
>>> Yes, mostly wrong things. I think it would be a huge loss if D copied C++'s model.
>> 
>> This means that structs cannot hold on external resources, ever:
>> 
>>     struct RAII {...}
>>     var a = RAII("foo");
>>     var b = RAII("bar");
>>     a = b; // you just leaked a and corrupted b
> 
> You may be making a confusion between assignment and copy construction.

Sure I'm confusing them, silly me.

The only thing copy-construction is useful for is implementing move semantics, think std::auto_ptr.  Seems like everything else can be done in post-blit.

The inability to overload opAssign(typeof(this)) is a blocker for robust
RAII though.
July 27, 2009
Adam D. Ruppe:

> Why is dedicated syntax for comma expressions better than commaExpr(...)?
>What do you propose we do about the commas in loops? Breaking them would be a pretty big change to the C folks.<

Disallowing bad usages of commas is a starting point. for() can become a special case. Handy syntax for tuple unpacking is useful in many situations, look at Python code.

Bye,
bearophile
(Late answer, sorry, I was away)
July 27, 2009
On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Ary Borenszweig wrote:
>> Maybe what scares Walter is a whole new syntax for properties.
>
> It doesn't scare me. It's trivial to add more syntax.
>
> It's just that D is complex enough - there needs to be some very good reasons for adding more syntax that has apparently zero semantic information that would be different from the usual function syntax.

OK, so you don't like the idea of adding dedicated properties.

What is *your* solution to forbidding abuses like this:

writefln = "hi";

???

-Steve
July 27, 2009
On Mon, Jul 27, 2009 at 7:13 AM, Steven Schveighoffer<schveiguy@yahoo.com> wrote:
> On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
>
>> Ary Borenszweig wrote:
>>>
>>> Maybe what scares Walter is a whole new syntax for properties.
>>
>> It doesn't scare me. It's trivial to add more syntax.
>>
>> It's just that D is complex enough - there needs to be some very good reasons for adding more syntax that has apparently zero semantic information that would be different from the usual function syntax.
>
> OK, so you don't like the idea of adding dedicated properties.
>
> What is *your* solution to forbidding abuses like this:
>
> writefln = "hi";
>
> ???
>

I think his suggestion was the Java-style approach -- special naming convention for get/set functions:

int opGet_foo() { return foo_; }
void opSet_foo(int foo) { foo_ = foo; }
private:
int foo_;

--bb
July 27, 2009
On Mon, 27 Jul 2009 13:23:42 -0400, Bill Baxter <wbaxter@gmail.com> wrote:

> On Mon, Jul 27, 2009 at 7:13 AM, Steven
> Schveighoffer<schveiguy@yahoo.com> wrote:
>> On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>
>>> Ary Borenszweig wrote:
>>>>
>>>> Maybe what scares Walter is a whole new syntax for properties.
>>>
>>> It doesn't scare me. It's trivial to add more syntax.
>>>
>>> It's just that D is complex enough - there needs to be some very good
>>> reasons for adding more syntax that has apparently zero semantic information
>>> that would be different from the usual function syntax.
>>
>> OK, so you don't like the idea of adding dedicated properties.
>>
>> What is *your* solution to forbidding abuses like this:
>>
>> writefln = "hi";
>>
>> ???
>>
>
> I think his suggestion was the Java-style approach -- special naming
> convention for get/set functions:
>
> int opGet_foo() { return foo_; }
> void opSet_foo(int foo) { foo_ = foo; }
> private:
> int foo_;

Really?  I got the impression that he does not think properties warrant any kind of special syntax.

If that's the solution it's ok with me, the only issue is name collision (as others have mentioned):

int opGet_foo()
int foo;

must be forbidden.  This is different from other opX operators since the true names of those operators cannot be symbols, and therefore could never have collisions.

-Steve
July 27, 2009
Bill Baxter wrote:
> On Mon, Jul 27, 2009 at 7:13 AM, Steven
> Schveighoffer<schveiguy@yahoo.com> wrote:
>> On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>
>>> Ary Borenszweig wrote:
>>>> Maybe what scares Walter is a whole new syntax for properties.
>>> It doesn't scare me. It's trivial to add more syntax.
>>>
>>> It's just that D is complex enough - there needs to be some very good
>>> reasons for adding more syntax that has apparently zero semantic information
>>> that would be different from the usual function syntax.
>> OK, so you don't like the idea of adding dedicated properties.
>>
>> What is *your* solution to forbidding abuses like this:
>>
>> writefln = "hi";
>>
>> ???
>>
> 
> I think his suggestion was the Java-style approach -- special naming
> convention for get/set functions:
> 
> int opGet_foo() { return foo_; }
> void opSet_foo(int foo) { foo_ = foo; }
> private:
> int foo_;
> 
> --bb

For one thing I like that I now get to define empty() for a range and then call it with r.empty. I'd think it would be a small step backward if I had to define get_empty() or something instead.

Andrei
July 27, 2009
Sergey Gromov wrote:
> The only thing copy-construction is useful for is implementing move semantics, think std::auto_ptr.  Seems like everything else can be done in post-blit.

The "linked list" implementation of smart pointers also requires a copy constructor.  It's (arguably) not a very good design, but it is a valid design.

> The inability to overload opAssign(typeof(this)) is a blocker for robust
> RAII though.

Yes.


-- 
Rainer Deyke - rainerd@eldwood.com
July 27, 2009
On Mon, 27 Jul 2009 13:59:53 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Bill Baxter wrote:
>> On Mon, Jul 27, 2009 at 7:13 AM, Steven
>> Schveighoffer<schveiguy@yahoo.com> wrote:
>>> On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
>>> <newshound1@digitalmars.com> wrote:
>>>
>>>> Ary Borenszweig wrote:
>>>>> Maybe what scares Walter is a whole new syntax for properties.
>>>> It doesn't scare me. It's trivial to add more syntax.
>>>>
>>>> It's just that D is complex enough - there needs to be some very good
>>>> reasons for adding more syntax that has apparently zero semantic information
>>>> that would be different from the usual function syntax.
>>> OK, so you don't like the idea of adding dedicated properties.
>>>
>>> What is *your* solution to forbidding abuses like this:
>>>
>>> writefln = "hi";
>>>
>>> ???
>>>
>>  I think his suggestion was the Java-style approach -- special naming
>> convention for get/set functions:
>>  int opGet_foo() { return foo_; }
>> void opSet_foo(int foo) { foo_ = foo; }
>> private:
>> int foo_;
>>  --bb
>
> For one thing I like that I now get to define empty() for a range and then call it with r.empty. I'd think it would be a small step backward if I had to define get_empty() or something instead.

The "getter" notation that currently exists only has a few minor problems.  The most major of those problems is if the return value is a callable type, such as a delegate, you can't easily perform the call on the returned value.  Being that it isn't very bad for the getter property, would it make sense to leave that functionality?  That is:

1. A setter must be defined in the opSet_X(int x) form
2. A getter can be a function with no required arguments, but this getter should not return callable types
3. A getter can be defined in the opGet_X() form, and then using X() will be the eqivalent of opGet_X()().

There are small implications to leaving the existing getter syntax.  Namely one can call a function not intended to be a getter in a property-like syntax, resulting in less-than-obvious code.  Also, this distinction will be very hard to explain to newbies ("how come a getter is defined as x(), but a setter has to be opSet_x(...)?).

The more I look at it, the more I like the keyword solution.  I do find the C#-like syntax which groups properties together appealing, but I think you only absolutely need that if you are going to have context-keywords, which I DON'T think we need.  I do find the whole construct of C# properties tedious to type.

With a keyword attribute, you could even group your properties together to save on typing/ugliness:

property
{
   int x() {}
   void x(int n) {}
   bool empty() {}
}

-Steve
July 27, 2009
Steven Schveighoffer:
> property
> {
>     int x() {}
>     void x(int n) {}
>     bool empty() {}
> }

An alternative:

property(x) {
    ... // or getter and/or setter
}

Bye,
bearophile