On Sunday, 9 December 2012 at 16:26:12 UTC, Jacob Carlborg wrote:
On 2012-12-09 15:45, Dan wrote:
Phobos can and should have a general dup function, capable of
duping
(i.e. recursive deep copy) structs without requiring any
effort from
struct developers.
[snip]
I think much of this
On 2012-12-10 13:56, Dan wrote:
However, if template mixins are preferred to
string mixins I suppose that is a good idea for that code and I'll check
it out.
Yes, templates are always preferred. One should try to avoid putting
code in string literals as much as possible.
--
/Jacob Carlborg
On 12/09/2012 03:45 PM, Dan wrote:
Phobos can and should have a general dup function, capable of duping (i.e.
recursive deep copy) structs without requiring any effort from struct
developers. This can be done to cover the vast majority of object copy issues
for structs
We already had some
On Monday, 10 December 2012 at 15:36:44 UTC, Joseph Rushton
Wakeling wrote:
On 12/09/2012 03:45 PM, Dan wrote:
Phobos can and should have a general dup function, capable of
duping (i.e.
recursive deep copy) structs without requiring any effort from
struct
developers. This can be done to cover
On 2012-12-10 17:06, Dan wrote:
I think so. Here is a claim I think is true: gdup must do full deep copy
to be safe and guarantee the transitive const/immutable. If it is
implemented such that there are no casts, then the compiler does its job
and ensures everything is good. If there are casts
On Monday, 10 December 2012 at 18:55:09 UTC, Jacob Carlborg wrote:
I'm pretty sure it can't be done. For classes one need to
bypass the constructor. The constructor is the only place where
you can initialize const/immutable fields. For class instance
one would need to cast it to a ubyte
On 2012-12-10 20:07, Dan wrote:
Only talking about structs here. classes were listed under issues not
covered.
You might have the same problem with structs. That is, if it's possible
to have const/immutable files which are not initialized in the declaration.
--
/Jacob Carlborg
On 2012-12-10 20:37, Jacob Carlborg wrote:
You might have the same problem with structs. That is, if it's possible
to have const/immutable files which are not initialized in the declaration.
That should have been fields.
--
/Jacob Carlborg
On 12/10/12 1:55 PM, Jacob Carlborg wrote:
On 2012-12-10 17:06, Dan wrote:
I think so. Here is a claim I think is true: gdup must do full deep copy
to be safe and guarantee the transitive const/immutable. If it is
implemented such that there are no casts, then the compiler does its job
and
On 12/10/12 2:07 PM, Dan wrote:
On Monday, 10 December 2012 at 18:55:09 UTC, Jacob Carlborg wrote:
I'm pretty sure it can't be done. For classes one need to bypass the
constructor. The constructor is the only place where you can
initialize const/immutable fields. For class instance one would
On Monday, 10 December 2012 at 19:46:18 UTC, Andrei Alexandrescu
wrote:
On 12/10/12 1:55 PM, Jacob Carlborg wrote:
On 2012-12-10 17:06, Dan wrote:
I think so. Here is a claim I think is true: gdup must do
full deep copy
to be safe and guarantee the transitive const/immutable. If
it is
On 2012-12-10 20:46, Andrei Alexandrescu wrote:
Just like Dan I thought it can be done but actually ownership is
impossible to establish in general. Consider:
class List(T) {
List next;
T payload;
...
}
versus
class Window {
Window parent;
...
}
It's pretty obvious
On 2012-12-10 20:55, Dan wrote:
You are correct. const or immutable fields won't work. But then, if you
had a field that was const or immutable you might as well make it
static. Any problems with gdup in that case would be the same you would
see if you wanted to implement your own.
As I wrote
On Monday, 10 December 2012 at 19:40:52 UTC, Jacob Carlborg wrote:
On 2012-12-10 20:37, Jacob Carlborg wrote:
You might have the same problem with structs. That is, if it's
possible
to have const/immutable files which are not initialized in the
declaration.
That should have been fields.
On 12/10/12 2:54 PM, Jacob Carlborg wrote:
On 2012-12-10 20:46, Andrei Alexandrescu wrote:
Just like Dan I thought it can be done but actually ownership is
impossible to establish in general. Consider:
class List(T) {
List next;
T payload;
...
}
versus
class Window {
Window parent;
...
}
On Monday, 10 December 2012 at 20:10:25 UTC, Andrei Alexandrescu
wrote:
You want to create a new window with the same parent. At the
top level there's one desktop window, and probably having two
would be odd.
Ok - so I'm only talking about structs.
What you say is what you want here and
On 2012-12-10 21:10, Andrei Alexandrescu wrote:
You want to create a new window with the same parent. At the top level
there's one desktop window, and probably having two would be odd.
There are many applications that support several top level windows.
These are mostly document based.
--
On 12/10/12 4:20 PM, Jacob Carlborg wrote:
On 2012-12-10 21:10, Andrei Alexandrescu wrote:
You want to create a new window with the same parent. At the top level
there's one desktop window, and probably having two would be odd.
There are many applications that support several top level
On Monday, 10 December 2012 at 21:24:09 UTC, Andrei Alexandrescu
wrote:
On 12/10/12 4:20 PM, Jacob Carlborg wrote:
On 2012-12-10 21:10, Andrei Alexandrescu wrote:
You want to create a new window with the same parent. At the
top level
there's one desktop window, and probably having two would
On 2012-12-10 22:24, Andrei Alexandrescu wrote:
Are we really up for continuing to debate this?
No, not really. It's kind of a useless discussion. End.
--
/Jacob Carlborg
On 2012-12-09 15:45, Dan wrote:
Phobos can and should have a general dup function, capable of duping
(i.e. recursive deep copy) structs without requiring any effort from
struct developers.
[snip]
I think much of this functionality could be shared with serialization. A
few questions and
21 matches
Mail list logo
