On 03/10/2010 12:14 PM, bearophile wrote:
Andrei Alexandrescu:
That's a bug worth submitting.
OK:
http://d.puremagic.com/issues/show_bug.cgi?id=3927
(I have not started fixing bugs)
Bye,
bearophile
BTW I noticed that you have recently submitted a great deal of bugs and
good suggestions to
On Fri, 12 Mar 2010 04:06:27 -0500, Pelle Månsson
wrote:
On 03/11/2010 09:37 PM, Steven Schveighoffer wrote:
BTW, C# doesn't do this:
-Steve
I still think D should, it makes little sense not to. What is gained
from limiting arbitrarily?
It has been pointed out that C#'s properties are
On 03/11/2010 09:37 PM, Steven Schveighoffer wrote:
BTW, C# doesn't do this:
-Steve
I still think D should, it makes little sense not to. What is gained
from limiting arbitrarily?
Thu, 11 Mar 2010 15:37:59 -0500, Steven Schveighoffer wrote:
> On Wed, 10 Mar 2010 17:16:11 -0500, Pelle Månsson
> wrote:
>
>> On 03/10/2010 10:14 PM, Steven Schveighoffer wrote:
>>> I think this is fine as long as we don't take it to the extreme. That
>>> is, I don't want to see this happening:
Andrei Alexandrescu wrote:
> On 03/10/2010 09:14 PM, Chad J wrote:
>> ...
>> Indexing seems to be the general case of properties: an indexed
>> expression can be a getter/setter pair identified by both an identifier
>> (the property's name: opIndex in this case) and some runtime variables
>> (the i
On Wed, 10 Mar 2010 17:16:11 -0500, Pelle Månsson
wrote:
On 03/10/2010 10:14 PM, Steven Schveighoffer wrote:
I think this is fine as long as we don't take it to the extreme. That
is, I don't want to see this happening:
foo.prop1.prop2++;
is rewritten to
auto p1 = foo.prop1;
auto p2 = p1.p
On 03/10/2010 09:14 PM, Chad J wrote:
Andrei Alexandrescu wrote:
Well operator overloading handles indexing differently, and arguably
better than in your proposal. Ideally we'd define operators on
properties in a manner similar to the way indexing works in the new
operator overloading scheme. I'
On Wed, 10 Mar 2010 17:16:11 -0500, Pelle Månsson
wrote:
On 03/10/2010 10:14 PM, Steven Schveighoffer wrote:
I think this is fine as long as we don't take it to the extreme. That
is, I don't want to see this happening:
foo.prop1.prop2++;
is rewritten to
auto p1 = foo.prop1;
auto p2 = p1.p
Andrei Alexandrescu wrote:
> On 03/09/2010 09:48 PM, Chad J wrote:
>> I speak of the property rewriting where an expression like
>>
>> foo.prop++;
>>
>> is rewritten as
>>
>> auto t = foo.prop();
>> t++;
>> foo.prop(t);
>
> This particular example has a number of issues. First
On 03/10/2010 10:14 PM, Steven Schveighoffer wrote:
I think this is fine as long as we don't take it to the extreme. That
is, I don't want to see this happening:
foo.prop1.prop2++;
is rewritten to
auto p1 = foo.prop1;
auto p2 = p1.prop2;
p2++;
p1.prop2 = p2;
foo.prop1 = p1;
I think one level
On Tue, 09 Mar 2010 22:48:08 -0500, Chad J
wrote:
I speak of the property rewriting where an expression like
foo.prop++;
is rewritten as
auto t = foo.prop();
t++;
foo.prop(t);
I think this is fine as long as we don't take it to the extreme. That is,
I don't want to s
On 03/10/2010 01:05 PM, bearophile wrote:
Andrei Alexandrescu:
integration of interpretation with compilation,
Isn't it better to use the compiler to run the functions at compile
time, in a staged compilation? This removes the development&
maintenance burden of the interpreter, that must be ke
Andrei Alexandrescu:
> integration of interpretation with compilation,
Isn't it better to use the compiler to run the functions at compile time, in a
staged compilation? This removes the development & maintenance burden of the
interpreter, that must be kept in sync with the semantics of the main
Andrei Alexandrescu:
> That's a bug worth submitting.
OK:
http://d.puremagic.com/issues/show_bug.cgi?id=3927
(I have not started fixing bugs)
Bye,
bearophile
On 03/10/2010 11:10 AM, Andrei Alexandrescu wrote:
On 03/10/2010 11:05 AM, Ellery Newcomer wrote:
On 03/10/2010 10:48 AM, Andrei Alexandrescu wrote:
On 03/10/2010 08:42 AM, Andrei Alexandrescu wrote:
{auto t = foo.prop; auto t1 = t; ++t1; foo.prop = t1; return t;}()
within an rvalue context,
On 03/10/2010 11:05 AM, Ellery Newcomer wrote:
On 03/10/2010 10:48 AM, Andrei Alexandrescu wrote:
On 03/10/2010 08:42 AM, Andrei Alexandrescu wrote:
{auto t = foo.prop; auto t1 = t; ++t1; foo.prop = t1; return t;}()
within an rvalue context, and into:
{auto t = foo.prop; ++t; foo.prop = t; re
On 03/10/2010 10:48 AM, Andrei Alexandrescu wrote:
On 03/10/2010 08:42 AM, Andrei Alexandrescu wrote:
{auto t = foo.prop; auto t1 = t; ++t1; foo.prop = t1; return t;}()
within an rvalue context, and into:
{auto t = foo.prop; ++t; foo.prop = t; return t;}()
within a void context.
The latter
On 03/10/2010 08:42 AM, Andrei Alexandrescu wrote:
On 03/09/2010 09:48 PM, Chad J wrote:
I speak of the property rewriting where an expression like
foo.prop++;
is rewritten as
auto t = foo.prop();
t++;
foo.prop(t);
This particular example has a number of issues. First off you need to
rewrit
On 03/10/2010 09:12 AM, retard wrote:
Wed, 10 Mar 2010 08:53:57 -0600, Andrei Alexandrescu wrote:
On 03/10/2010 04:38 AM, retard wrote:
Wed, 10 Mar 2010 10:05:03 +, retard wrote:
This is so unbelievable. I knew the property stuff was being
redesigned since there was so much talk in the n
On 03/10/2010 09:23 AM, bearophile wrote:
Andrei Alexandrescu:
The idea is sensible and is already in effect for the ".length" property
of arrays.
I didn't know that. So I have tried this code:
void main() {
int[] a;
a.length++;
a.length--;
}
The compiler shows the following e
On 03/10/2010 04:23 PM, bearophile wrote:
Andrei Alexandrescu:
The idea is sensible and is already in effect for the ".length" property
of arrays.
I didn't know that. So I have tried this code:
void main() {
int[] a;
a.length++;
a.length--;
}
The compiler shows the following e
Andrei Alexandrescu:
> The idea is sensible and is already in effect for the ".length" property
> of arrays.
I didn't know that. So I have tried this code:
void main() {
int[] a;
a.length++;
a.length--;
}
The compiler shows the following errors, is this correct?
test1.d(3): Error: a
Wed, 10 Mar 2010 08:53:57 -0600, Andrei Alexandrescu wrote:
> On 03/10/2010 04:38 AM, retard wrote:
>> Wed, 10 Mar 2010 10:05:03 +, retard wrote:
>>
>>> This is so unbelievable. I knew the property stuff was being
>>> redesigned since there was so much talk in the ng some time ago. But
>>> eve
On 03/10/2010 04:38 AM, retard wrote:
Wed, 10 Mar 2010 10:05:03 +, retard wrote:
This is so unbelievable. I knew the property stuff was being redesigned
since there was so much talk in the ng some time ago. But even now, why
on earth doesn't it work like it should. Is it so hard to copy/ste
On 03/09/2010 09:48 PM, Chad J wrote:
I speak of the property rewriting where an expression like
foo.prop++;
is rewritten as
auto t = foo.prop();
t++;
foo.prop(t);
This particular example has a number of issues. First off you need to
rewrite expressions, not statements.
Wed, 10 Mar 2010 10:05:03 +, retard wrote:
> This is so unbelievable. I knew the property stuff was being redesigned
> since there was so much talk in the ng some time ago. But even now, why
> on earth doesn't it work like it should. Is it so hard to copy/steal the
> good ideas from the better
Tue, 09 Mar 2010 22:48:08 -0500, Chad J wrote:
> I speak of the property rewriting where an expression like
>
> foo.prop++;
>
> is rewritten as
>
> auto t = foo.prop();
> t++;
> foo.prop(t);
>
>
> So, Walter or Andrei or someone on the planning behind the scenes,
> please lend
I speak of the property rewriting where an expression like
foo.prop++;
is rewritten as
auto t = foo.prop();
t++;
foo.prop(t);
So, Walter or Andrei or someone on the planning behind the scenes,
please lend me your thoughts:
How much time is left to make this sort of thing happen
28 matches
Mail list logo
