The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
I don't see how C#'s special property syntax adds any value for dealing
with this.
One thought I had was
Walter Bright escribió:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
I don't see how C#'s special property syntax adds any value for dealing
with this
Walter Bright wrote:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
I don't see how C#'s special property syntax adds any value for dealing
with this.
BLS wrote:
What I don't see is why a property isn't just a property. What you
announce is more a kind of "universal maybe these value holder"
- a temporary object is not a property period
Even returning an 'int' is a temporary object.
BLS wrote:
Walter Bright wrote:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
I don't see how C#'s special property syntax adds any value for
dealing
Walter Bright wrote:
BLS wrote:
What I don't see is why a property isn't just a property. What you
announce is more a kind of "universal maybe these value holder"
- a temporary object is not a property period
Even returning an 'int' is a temporary object.
?
BLS wrote:
BLS wrote:
Walter Bright wrote:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as
functions.
I don't see how C#'s special property syntax adds any value
在 Wed, 29 Jul 2009 10:33:53 +0800，Walter Bright
写道:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
I don't see how C#'s special property syntax adds
Andrei Alexandrescu wrote:
BLS wrote:
BLS wrote:
Walter Bright wrote:
The issue is what if b is a property, returns a temporary object,
and that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as
functions.
I don't see how C#'s special pr
Walter Bright wrote:
> The issue is what if b is a property, returns a temporary object, and
> that temp's .c field is uselessly set to 3?
>
> It's a classic problem with properties that are implemented as functions.
>
> I don't see how C#'s special property syntax adds any value for dealing
>
On Tue, Jul 28, 2009 at 10:33 PM, Walter
Bright wrote:
> The issue is what if b is a property, returns a temporary object, and that
> temp's .c field is uselessly set to 3?
So, the issue is that 'a.b()' returns a struct by value. Such return
values should always be considered rvalues. Furthermor
"BLS" wrote in message
news:h4oeb0$5s...@digitalmars.com...
> Walter Bright wrote:
>> BLS wrote:
>>> What I don't see is why a property isn't just a property. What you
>>> announce is more a kind of "universal maybe these value holder"
>>> - a temporary object is not a property period
>>
>> Even
"Daniel Keep" wrote in message
news:h4og1p$b3...@digitalmars.com...
>
> Walter Bright wrote:
>> The issue is what if b is a property, returns a temporary object, and
>> that temp's .c field is uselessly set to 3?
>>
>> It's a classic problem with properties that are implemented as functions.
>>
>
davidl wrote:
A property should never return temp obj in the first place.
That's unworkable - it means you cannot have user defined types.
Daniel Keep wrote:
>
> Walter Bright wrote:
>> The issue is what if b is a property, returns a temporary object, and
>> that temp's .c field is uselessly set to 3?
>>
>> It's a classic problem with properties that are implemented as functions.
>>
>> I don't see how C#'s special property syntax add
Jarrett Billingsley wrote:
> On Tue, Jul 28, 2009 at 10:33 PM, Walter
> Bright wrote:
>> The issue is what if b is a property, returns a temporary object, and that
>> temp's .c field is uselessly set to 3?
>
> So, the issue is that 'a.b()' returns a struct by value. Such return
> values should
Walter Bright Wrote:
> The issue is what if b is a property, returns a temporary object, and
> that temp's .c field is uselessly set to 3?
>
> It's a classic problem with properties that are implemented as functions.
Does this problem pertain to properties?
Look at this:
void main()
{
int a=
Kagamin wrote:
Walter Bright Wrote:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
Does this problem pertain to properties?
Look at this:
void main()
Andrei Alexandrescu Wrote:
> The code above is only loosely related. The code above contains a
> definition initiated by the user.
True, but is there any technical difference for compiler? How the usefulness of
the code change depending on whether it's written by the user or... huh?..
don't kn
Daniel Keep Wrote:
> Maybe the compiler could rewrite the above as:
>
> auto t = a.b;
> t.c = 3;
> a.b = t;
>
> Unless it can prove it doesn't need to. Same solution as to the op=
> conundrum.
I think b should be const if it is a temporary object.
And the compiler will tell you that a.b.c is
Kagamin wrote:
Andrei Alexandrescu Wrote:
The question is very simple: given that we're used with a specific
semantics for a.b.c = 3, how can we address the fact that the semantics
of this familiar operation is so different (and likely so useless) when
properties replace fields?
You're solvi
"Ary Borenszweig" wrote in message
news:h4ocm1$28...@digitalmars.com...
Walter Bright escribió:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
I don'
Andrei Alexandrescu Wrote:
> Kagamin wrote:
> > Andrei Alexandrescu Wrote:
> >> The question is very simple: given that we're used with a specific
> >> semantics for a.b.c = 3, how can we address the fact that the semantics
> >> of this familiar operation is so different (and likely so useless)
Walter Bright wrote:
davidl wrote:
A property should never return temp obj in the first place.
That's unworkable - it means you cannot have user defined types.
I would like to say that if a class/ structure _is_ a property than it
has to be declared as immutable, otherwise it is _not_ a pro
Walter Bright wrote:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
I don't see how C#'s special property syntax adds any value for dealing
with this.
Lionello Lunesu wrote:
"Ary Borenszweig" wrote in message
news:h4ocm1$28...@digitalmars.com...
Walter Bright escribió:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implement
On 2009-07-28 22:33:53 -0400, Walter Bright said:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
With the local namespace approach I propsed a little
BLS Wrote:
> Andrei Alexandrescu wrote:
> > BLS wrote:
> >> BLS wrote:
> >>> Walter Bright wrote:
> The issue is what if b is a property, returns a temporary object,
> and that temp's .c field is uselessly set to 3?
>
> It's a classic problem with properties that are implement
On Wed, Jul 29, 2009 at 1:08 AM, Daniel Keep wrote:
>
>
> Jarrett Billingsley wrote:
>> On Tue, Jul 28, 2009 at 10:33 PM, Walter
>> Bright wrote:
>>> The issue is what if b is a property, returns a temporary object, and that
>>> temp's .c field is uselessly set to 3?
>>
>> So, the issue is that 'a.
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
Unless it can prove it doesn't need to. Same solution as to the op=
conundrum.
Yes! At least that's what the user wants.
The compiler has to detect, that the object was modified at all. (To
kn
Kagamin wrote:
Andrei Alexandrescu Wrote:
Kagamin wrote:
Andrei Alexandrescu Wrote:
The question is very simple: given that we're used with a
specific semantics for a.b.c = 3, how can we address the fact
that the semantics of this familiar operation is so different
(and likely so useless) whe
Michel Fortin wrote:
On 2009-07-28 22:33:53 -0400, Walter Bright
said:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
With the local namespace appro
On Wed, 29 Jul 2009 18:36:07 +0400, Andrei Alexandrescu
wrote:
Kagamin wrote:
Andrei Alexandrescu Wrote:
Kagamin wrote:
Andrei Alexandrescu Wrote:
The question is very simple: given that we're used with a
specific semantics for a.b.c = 3, how can we address the fact
that the semantics of
Andrei Alexandrescu wrote:
Kagamin wrote:
Andrei Alexandrescu Wrote:
Kagamin wrote:
Andrei Alexandrescu Wrote:
The question is very simple: given that we're used with a
specific semantics for a.b.c = 3, how can we address the fact
that the semantics of this familiar operation is so different
On Wed, Jul 29, 2009 at 10:44 AM, Ary Borenszweig wrote:
> Andrei Alexandrescu wrote:
>>
>> Kagamin wrote:
>>>
>>> Andrei Alexandrescu Wrote:
>>>
Kagamin wrote:
>
> Andrei Alexandrescu Wrote:
>>
>> The question is very simple: given that we're used with a
>> specific semant
On Wed, Jul 29, 2009 at 9:23 AM, Jarrett
Billingsley wrote:
> On Wed, Jul 29, 2009 at 10:44 AM, Ary Borenszweig
> wrote:
>> Andrei Alexandrescu wrote:
>>>
>>> Kagamin wrote:
Andrei Alexandrescu Wrote:
> Kagamin wrote:
>>
>> Andrei Alexandrescu Wrote:
>>>
>>> The
On Tue, 28 Jul 2009 22:33:53 -0400, Walter Bright
wrote:
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
There's one way you could do it -- since the return value is a temporary,
it should not be an lvalue. But it's membe
Reply to Walter,
The issue is what if b is a property, returns a temporary object, and
that temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as
functions.
I don't see how C#'s special property syntax adds any value for
dealing with this.
One t
Bill Baxter wrote:
On Wed, Jul 29, 2009 at 9:23 AM, Jarrett
Billingsley wrote:
On Wed, Jul 29, 2009 at 10:44 AM, Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Kagamin wrote:
Andrei Alexandrescu Wrote:
Kagamin wrote:
Andrei Alexandrescu Wrote:
The question is very simple: given that we
On Wed, Jul 29, 2009 at 10:11 AM, KennyTM~ wrote:
> Bill Baxter wrote:
>>
>> On Wed, Jul 29, 2009 at 9:23 AM, Jarrett
>> Billingsley wrote:
>>>
>>> On Wed, Jul 29, 2009 at 10:44 AM, Ary Borenszweig
>>> wrote:
Andrei Alexandrescu wrote:
>
> Kagamin wrote:
>>
>> Andrei Alexa
On Wed, Jul 29, 2009 at 10:11 AM, KennyTM~ wrote:
> Bill Baxter wrote:
>>
>> On Wed, Jul 29, 2009 at 9:23 AM, Jarrett
>> Billingsley wrote:
>>>
>>> On Wed, Jul 29, 2009 at 10:44 AM, Ary Borenszweig
>>> wrote:
Andrei Alexandrescu wrote:
>
> Kagamin wrote:
>>
>> Andrei Alexa
Ary Borenszweig wrote:
> Andrei Alexandrescu wrote:
>> Kagamin wrote:
>>> Andrei Alexandrescu Wrote:
>>>
Kagamin wrote:
> Andrei Alexandrescu Wrote:
>> The question is very simple: given that we're used with a
>> specific semantics for a.b.c = 3, how can we address the fact
>>
On Wed, 29 Jul 2009 13:22:14 -0400, Bill Baxter wrote:
Similarly, taking the address should lead to an error.
auto ptr = &a.b; // ok if b is a field
auto ptr = &a.b; // bogus if b is a property returning a non-lvalue
Impossible with the current implementation -- &a.b is a delegate :)
-Stev
On Wed, Jul 29, 2009 at 10:26 AM, Steven
Schveighoffer wrote:
> On Wed, 29 Jul 2009 13:22:14 -0400, Bill Baxter wrote:
>
>> Similarly, taking the address should lead to an error.
>>
>> auto ptr = &a.b; // ok if b is a field
>> auto ptr = &a.b; // bogus if b is a property returning a non-lvalue
>
On Wed, Jul 29, 2009 at 10:36 AM, Bill Baxter wrote:
> On Wed, Jul 29, 2009 at 10:26 AM, Steven
> Schveighoffer wrote:
>> On Wed, 29 Jul 2009 13:22:14 -0400, Bill Baxter wrote:
>>
>>> Similarly, taking the address should lead to an error.
>>>
>>> auto ptr = &a.b; // ok if b is a field
>>> auto pt
Bill Baxter wrote:
Yeh, I don't understand how any of this has anything to do with
properties. It's the same question if you ask what should
a.b().c = 5
do. It's the same issue whether you have properties or not, and
needs a solution whether you have properties or not.
Well the problem is
Wed, 29 Jul 2009 13:39:50 +1000, Daniel Keep wrote:
> Walter Bright wrote:
>> The issue is what if b is a property, returns a temporary object, and
>> that temp's .c field is uselessly set to 3?
>>
>> It's a classic problem with properties that are implemented as functions.
>>
>> I don't see how
Andrei Alexandrescu wrote:
Bill Baxter wrote:
Yeh, I don't understand how any of this has anything to do with
properties. It's the same question if you ask what should
a.b().c = 5
do. It's the same issue whether you have properties or not, and
needs a solution whether you have properties o
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Bill Baxter wrote:
Yeh, I don't understand how any of this has anything to do with
properties. It's the same question if you ask what should
a.b().c = 5
do. It's the same issue whether you have properties or not, and
needs a solution wheth
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
Unless it can prove it doesn't need to. Same solution as to the op=
conundrum.
Yes! At least that's what the u
On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
Unless it can prove it doesn't need to. Same solution as to the op=
conundrum.
Yes! At least that's what the user wants.
The compiler has
On Wed, Jul 29, 2009 at 10:50 AM, Andrei
Alexandrescu wrote:
> Bill Baxter wrote:
>>
>> Yeh, I don't understand how any of this has anything to do with
>> properties. It's the same question if you ask what should
>>
>> a.b().c = 5
>>
>> do. It's the same issue whether you have properties or not
On Wed, Jul 29, 2009 at 11:08 AM, Andrei
Alexandrescu wrote:
>
>> I don't believe the problem needs to be solved.
>
> To me it looks like an essential problem.
It's a problem, but not a problem of properties. Just a problem of
temporary return values in general.
--bb
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Bill Baxter wrote:
Yeh, I don't understand how any of this has anything to do with
properties. It's the same question if you ask what should
a.b().c = 5
do. It's the same issue whether you have properties or not
Bill Baxter wrote:
On Wed, Jul 29, 2009 at 10:50 AM, Andrei
Alexandrescu wrote:
Bill Baxter wrote:
Yeh, I don't understand how any of this has anything to do with
properties. It's the same question if you ask what should
a.b().c = 5
do. It's the same issue whether you have properties or n
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Bill Baxter wrote:
Yeh, I don't understand how any of this has anything to do with
properties. It's the same question if you ask what should
a.b().c = 5
do. It's the same issue whether yo
On Wed, 29 Jul 2009 14:08:18 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
It would be nice if the compiler could help by simply rejecting what it
can reject (assignment to rvalues), but other than that, there's not
much that can be done.
This can be detected in simple ca
Bill Baxter wrote:
On Wed, Jul 29, 2009 at 11:08 AM, Andrei
Alexandrescu wrote:
I don't believe the problem needs to be solved.
To me it looks like an essential problem.
It's a problem, but not a problem of properties. Just a problem of
temporary return values in general.
Yes. It is partic
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
Unless it can prove it doesn't need to. Same solution as to the op=
conundrum.
Yes! At least that's what the u
Steven Schveighoffer wrote:
> On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
>
>> Daniel Keep wrote:
>>> Maybe the compiler could rewrite the above as:
>>> auto t = a.b;
>>> t.c = 3;
>>> a.b = t;
>>> Unless it can prove it doesn't need to. Same solution as to the op=
>>> conundrum.
>>
>>
On Wed, 29 Jul 2009 14:22:26 -0400, grauzone wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
Unless it can prove it doesn't need to. Same solution as
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Bill Baxter wrote:
Yeh, I don't understand how any of this has anything to do with
properties. It's the same question if you ask what should
a.b().c = 5
do. It
Andrei Alexandrescu wrote:
Bill Baxter wrote:
On Wed, Jul 29, 2009 at 10:50 AM, Andrei
Alexandrescu wrote:
Bill Baxter wrote:
Yeh, I don't understand how any of this has anything to do with
properties. It's the same question if you ask what should
a.b().c = 5
do. It's the same issue whet
grauzone wrote:
> Steven Schveighoffer wrote:
>> On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
>>
>>> Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
Unless it can prove it doesn't need to. Same solution as to the
On Wed, 29 Jul 2009 14:39:07 -0400, Ary Borenszweig
wrote:
a.b.c = d;
If b is anything that has a struct type, and c is anything else, the
statement must report an error.
struct S
{
int *x;
void c(int n) {*x = n;}
}
struct S2
{
int n;
S b() { return S(&n);}
}
void main()
{
S2
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:39:07 -0400, Ary Borenszweig
wrote:
a.b.c = d;
If b is anything that has a struct type, and c is anything else, the
statement must report an error.
struct S
{
int *x;
void c(int n) {*x = n;}
}
struct S2
{
int n;
S b() { return S(
On Wed, 29 Jul 2009 14:50:42 -0400, Ary Borenszweig
wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:39:07 -0400, Ary Borenszweig
wrote:
a.b.c = d;
If b is anything that has a struct type, and c is anything else, the
statement must report an error.
struct S
{
int *x;
v
On Wed, 29 Jul 2009 14:46:11 -0400, Chad J
wrote:
grauzone wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
Unless it can prove it doesn't need to.
Steven Schveighoffer wrote:
> On Wed, 29 Jul 2009 14:46:11 -0400, Chad J
> wrote:
>
>> grauzone wrote:
>>> Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
> Daniel Keep wrote:
>> Maybe the compiler could rewrite the above as:
>> auto t = a.b
On Wed, 29 Jul 2009 14:50:42 -0400, Ary Borenszweig
wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:39:07 -0400, Ary Borenszweig
wrote:
a.b.c = d;
If b is anything that has a struct type, and c is anything else, the
statement must report an error.
struct S
{
int *x;
v
Steven Schveighoffer Wrote:
> On Wed, 29 Jul 2009 14:50:42 -0400, Ary Borenszweig
> wrote:
>
> > Steven Schveighoffer wrote:
> >> On Wed, 29 Jul 2009 14:39:07 -0400, Ary Borenszweig
> >> wrote:
> >>
> >>> a.b.c = d;
> >>>
> >>> If b is anything that has a struct type, and c is anything else
Steven Schveighoffer wrote:
> On Wed, 29 Jul 2009 14:22:26 -0400, grauzone wrote:
>
>> Steven Schveighoffer wrote:
>>> On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
>>>
Daniel Keep wrote:
> Maybe the compiler could rewrite the above as:
> auto t = a.b;
> t.c = 3;
> a.
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:22:26 -0400, grauzone wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
Unless it can prove it doesn'
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:08:18 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
It would be nice if the compiler could help by simply rejecting what
it can reject (assignment to rvalues), but other than that, there's
not much that can be done.
This ca
Chad J wrote:
> Steven Schveighoffer wrote:
>> Wouldn't the compiler write:
>>
>> //widget.rect.w = 200 translates to
>> auto tmp1 = widget.rect;
>> tmp1.w = 200;
>> widget.rect = tmp1;
>>
>> //widget.rect.h = 100 translates to
>> auto tmp2 = widget.rect;
>> tmp2.h = 100;
>> widget.rect = tmp2;
>>
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Bill Baxter wrote:
Yeh, I don't understand how any of this has anything to do with
properties. It's the same question if you ask what should
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:08:18 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
It would be nice if the compiler could help by simply rejecting what
it can reject (assignment to rvalues), but other than that, there's
not muc
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:39:07 -0400, Ary Borenszweig
wrote:
a.b.c = d;
If b is anything that has a struct type, and c is anything else, the
statement must report an error.
struct S
{
int *x;
void c(int n) {*x = n;}
}
struct S2
{
int n;
S b() { return S(
grauzone wrote:
> Steven Schveighoffer wrote:
>> option 2, return a special struct which uses properties to set the
>> values in the original widget.
>
> Now this would generate a mess (lots of bloat). Now I'm not sure; maybe
> macros could provide a way out (auto generate the code bloat), or
> po
Andrei Alexandrescu wrote:
> Ary Borenszweig wrote:
>> Not if b[5] is a struct. Do I need to list evey possible syntax there
>> it to get my point clear? :-(
>
> Yes, you actually need to. It was the point of my post.
Simple rule: rvalues cannot be modified (i.e. rvalues are implicitly
const). N
Chad J wrote:
> Steven Schveighoffer wrote:
>> On Wed, 29 Jul 2009 14:22:26 -0400, grauzone wrote:
>>
>>> Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
> Daniel Keep wrote:
>> Maybe the compiler could rewrite the above as:
>> auto t = a.b;
Chad J wrote:
Thinking about it a little more, the extra temporaries could run you out
of registers. That still sounds like a negligable cost in most code.
Temporaries can be on the stack. That's not a problem.
Andrei Alexandrescu wrote:
Bill Baxter wrote:
On Wed, Jul 29, 2009 at 11:08 AM, Andrei
Alexandrescu wrote:
I don't believe the problem needs to be solved.
To me it looks like an essential problem.
It's a problem, but not a problem of properties. Just a problem of
temporary return values in
On Wed, Jul 29, 2009 at 1:14 PM, grauzone wrote:
> Chad J wrote:
>>
>> Thinking about it a little more, the extra temporaries could run you out
>> of registers. That still sounds like a negligable cost in most code.
>
> Temporaries can be on the stack. That's not a problem.
>
How is that not a pe
Bill Baxter wrote:
> On Wed, Jul 29, 2009 at 1:14 PM, grauzone wrote:
>> Chad J wrote:
>>> Thinking about it a little more, the extra temporaries could run you out
>>> of registers. That still sounds like a negligable cost in most code.
>> Temporaries can be on the stack. That's not a problem.
>>
Chad J wrote:
> Bill Baxter wrote:
>> On Wed, Jul 29, 2009 at 1:14 PM, grauzone wrote:
>>> Chad J wrote:
Thinking about it a little more, the extra temporaries could run you out
of registers. That still sounds like a negligable cost in most code.
>>> Temporaries can be on the stack. That
On Wed, 29 Jul 2009 15:00:42 -0400, Ary Borenszweig
wrote:
Steven Schveighoffer Wrote:
On Wed, 29 Jul 2009 14:50:42 -0400, Ary Borenszweig
wrote:
> Steven Schveighoffer wrote:
>> On Wed, 29 Jul 2009 14:39:07 -0400, Ary Borenszweig
>> wrote:
>>
>>> a.b.c = d;
>>>
>>> If b is anything th
On Wed, 29 Jul 2009 15:01:47 -0400, Chad J
wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:22:26 -0400, grauzone wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 10:16:33 -0400, grauzone wrote:
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t
Steven Schveighoffer wrote:
> On Wed, 29 Jul 2009 15:01:47 -0400, Chad J
> wrote:
>>
>> So we could have semantics that actually work, but you don't want them
>> because, oh man, my code might have to do a few more assignments. A few
>> assignments. Really?!
>
> Hold on a second, don't we alrea
Chad J Wrote:
> Currently there are some cases where the current paradigm forces you to
> do that kind of work by hand:
>
> struct Rectangle
> {
> float x,y,w,h;
> }
> class Widget
> {
> Rectangle _rect;
> Rectangle rect() { return _rect; }
> Rectangle rect(Rectangle r) { r
Zhenyu Zhou wrote:
>
> What about:
>
> class Widget
> {
> Rectangle _rect;
> immutable(Rectangle) rect() const { return _rect; }
> Rectangle rect(Rectangle r) { return _rect = r; }
> }
You'll fall into the trap unless you know about immutable. Said another
way: the default is
Chad J Wrote:
> Zhenyu Zhou wrote:
> >
> > What about:
> >
> > class Widget
> > {
> > Rectangle _rect;
> > immutable(Rectangle) rect() const { return _rect; }
> > Rectangle rect(Rectangle r) { return _rect = r; }
> > }
>
> You'll fall into the trap unless you know about immutable. S
Zhenyu Zhou wrote:
> Chad J Wrote:
>> Zhenyu Zhou wrote:
>>> What about:
>>>
>>> class Widget
>>> {
>>> Rectangle _rect;
>>> immutable(Rectangle) rect() const { return _rect; }
>>> Rectangle rect(Rectangle r) { return _rect = r; }
>>> }
>> You'll fall into the trap unless you know about
On Wed, 29 Jul 2009 18:27:09 -0400, Chad J
wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 15:01:47 -0400, Chad J
wrote:
So we could have semantics that actually work, but you don't want them
because, oh man, my code might have to do a few more assignments. A
few
assignments.
On Wed, 29 Jul 2009 15:14:04 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:08:18 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
It would be nice if the compiler could help by simply rejecting what
it can reject (assignment to rvalu
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 15:14:04 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:08:18 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
It would be nice if the compiler could help by simply rejecting
what it can r
"Walter Bright" wrote in message
news:h4ocet$27...@digitalmars.com...
> The issue is what if b is a property, returns a temporary object, and that
> temp's .c field is uselessly set to 3?
>
> It's a classic problem with properties that are implemented as functions.
>
> I don't see how C#'s spec
"Zhenyu Zhou" wrote in message
news:h4rfif$2os...@digitalmars.com...
>
> e.g.
> Rectangle rect(Rectangle r) {
> _rect = r;
> redraw();
> return _rect;
> }
>
> If you allow
> widget.rect.w = 200;
> widget.rect.h = 100;
> you will have to write much more code to handle the painting correctly.
>
On Thu, 30 Jul 2009 14:09:06 -0400, Nick Sabalausky wrote:
"Zhenyu Zhou" wrote in message
news:h4rfif$2os...@digitalmars.com...
e.g.
Rectangle rect(Rectangle r) {
_rect = r;
redraw();
return _rect;
}
If you allow
widget.rect.w = 200;
widget.rect.h = 100;
you will have to write much more
"Chad J" wrote in message
news:h4oku0$ue...@digitalmars.com...
> Daniel Keep wrote:
>>
>> Maybe the compiler could rewrite the above as:
>>
>> auto t = a.b;
>> t.c = 3;
>> a.b = t;
>>
>
> I'd always suspected C# properties did something like this, though it's
> been so long since I've used C# now
1 - 100 of 116 matches
Mail list logo
