On 10/12/2010 20:58, Andrei Alexandrescu wrote:
On 12/10/10 12:46 PM, Steven Schveighoffer wrote:
On Mon, 06 Dec 2010 08:34:20 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sun, 05 Dec 2010 09:18:13 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Sorry, indeed I
On 10/12/2010 21:17, Andrei Alexandrescu wrote:
We all need to think about this a bit more because it's related to
another issue that I'm still losing sleep over: should we promote cheap
copy construction throughout D or not?
I was reminded of another comment that could be said in favor of
Brad Roberts wrote:
On 12/13/2010 2:54 PM, Don wrote:
I can't really escape the feeling that 'const' guarantees too little.
It makes guarantees to the caller, but tells the callee *nothing*.
As far as I'm concerned, that's exactly what I want const for. The caller can
rely on the object not
Jesse Phillips wrote:
Don Wrote:
I can't really escape the feeling that 'const' guarantees too little.
It makes guarantees to the caller, but tells the callee *nothing*.
But it tells the callee exactly what it does, (assuming you unintuitive associate that const objects can be modified).
On Mon, 13 Dec 2010 17:54:57 -0500, Don nos...@nospam.com wrote:
I can't really escape the feeling that 'const' guarantees too little.
It makes guarantees to the caller, but tells the callee *nothing*.
This is the basis of my argument that adding logical const would not
compromise the
Andrei Alexandrescu wrote:
On 12/10/10 4:10 PM, foobar wrote:
Don Wrote:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
I agree with don.
IMHO, this is
On 12/13/10 9:28 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/10/10 4:10 PM, foobar wrote:
Don Wrote:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
I
Andrei Alexandrescu wrote:
On 12/13/10 9:28 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/10/10 4:10 PM, foobar wrote:
Don Wrote:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of
On 2010-12-13 17:54:57 -0500, Don nos...@nospam.com said:
BTW the really big problem I have with 'auto ref' is that it isn't
'auto', and it isn't 'ref'. I wouldn't have the same objection to
something like 'autoref'.
I don't like auto ref as a syntax either, but I also dislike the
general
On 12/13/2010 2:54 PM, Don wrote:
I can't really escape the feeling that 'const' guarantees too little.
It makes guarantees to the caller, but tells the callee *nothing*.
As far as I'm concerned, that's exactly what I want const for. The caller can
rely on the object not being modified.
On Fri, 10 Dec 2010 21:25:49 -0500
Michel Fortin michel.for...@michelf.com wrote:
On 2010-12-10 17:12:16 -0500, Don nos...@nospam.com said:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent would
be:
void foo(auto ref const Widget)
On Fri, 10 Dec 2010 18:28:08 -0800
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
It's sort of ironic. Tu viens d'implementing yet another type
constructor yourself!
The need for yet another one signifie sûrement (probably means) their semantics
(in the human sense) are wrongly
Michel Fortin wrote:
On 2010-12-10 17:12:16 -0500, Don nos...@nospam.com said:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
One problem I'm starting to
On 2010-12-10 19:32:30 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 12/10/10 4:10 PM, foobar wrote:
Don Wrote:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of
On 12/11/10 2:49 CST, spir wrote:
On Fri, 10 Dec 2010 18:28:08 -0800
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote:
It's sort of ironic. Tu viens d'implementing yet another type
constructor yourself!
The need for yet another one signifie sûrement (probably means) their semantics
On Sat, 11 Dec 2010 09:06:33 -0500
Michel Fortin michel.for...@michelf.com wrote:
On 2010-12-10 19:32:30 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 12/10/10 4:10 PM, foobar wrote:
Don Wrote:
Steven Schveighoffer wrote:
To summarize for those looking for the
On 2010-12-11 11:48:36 -0500, spir denis.s...@gmail.com said:
If parameters are 'in' or 'const' by default, then whether they are passed
by value or by ref has no consequence, I guess. The compiler can then safel
y choose the most efficent more --what it can do as it knows sizeof-- gross
ly
If parameters are 'in' or 'const' by default, then whether they are
passed by value or by ref has no consequence, I guess. The compiler can
then safely choose the most efficent more --what it can do as it knows
sizeof-- grossly structs by ref, the rest by value. Is this reasoning
correct?
On Mon, 06 Dec 2010 08:34:20 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sun, 05 Dec 2010 09:18:13 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/5/10 12:04 AM, Steven Schveighoffer wrote:
I'm totally confused. I thought the point of auto ref was to
On 12/10/10 12:46 PM, Steven Schveighoffer wrote:
On Mon, 06 Dec 2010 08:34:20 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sun, 05 Dec 2010 09:18:13 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/5/10 12:04 AM, Steven Schveighoffer wrote:
I'm totally
On Fri, 10 Dec 2010 15:58:17 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/10/10 12:46 PM, Steven Schveighoffer wrote:
On Mon, 06 Dec 2010 08:34:20 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sun, 05 Dec 2010 09:18:13 -0500, Andrei Alexandrescu
On 12/10/10 1:10 PM, Steven Schveighoffer wrote:
On Fri, 10 Dec 2010 15:58:17 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/10/10 12:46 PM, Steven Schveighoffer wrote:
On Mon, 06 Dec 2010 08:34:20 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sun, 05 Dec
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
On 12/10/2010 10:58 PM, Andrei Alexandrescu wrote:
On 12/10/10 12:46 PM, Steven Schveighoffer wrote:
On Mon, 06 Dec 2010 08:34:20 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sun, 05 Dec 2010 09:18:13 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/5/10
Thanks a lot for taking time to explain!
Anybody interested see the rationale explained in detail at
http://thbecker.net/articles/rvalue_references/section_07.html or
http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/
Thanks, I had trouble understanding what this whole rvalue
On 12/11/10, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
Thanks a lot for taking time to explain!
Anybody interested see the rationale explained in detail at
http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/
Thanks, I had trouble understanding what this whole rvalue deal
On 12/11/10, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On 12/11/10, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
Thanks a lot for taking time to explain!
Anybody interested see the rationale explained in detail at
http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/
On 12/11/10, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On 12/11/10, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
Thanks a lot for taking time to explain!
Anybody interested see the rationale explained in detail at
http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/
Don Wrote:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
I agree with don.
IMHO, this is incredibly silly given Andrei's use case, since D can have
On 12/10/10 4:10 PM, foobar wrote:
Don Wrote:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
I agree with don.
IMHO, this is incredibly silly given Andrei's
I agree with don.
IMHO, this is incredibly silly given Andrei's use case, since D can have
instead:
void foo(const Widget);
and have an optimization inside the compiler for value types to pass by
ref.
by specifying const ref you explicitly require that only a ref to an
l-value be
On 2010-12-10 17:12:16 -0500, Don nos...@nospam.com said:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
One problem I'm starting to realize is that we now have
On 12/10/10 6:25 PM, Michel Fortin wrote:
On 2010-12-10 17:12:16 -0500, Don nos...@nospam.com said:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
One problem
On 12/10/10 6:25 PM, Michel Fortin wrote:
On 2010-12-10 17:12:16 -0500, Don nos...@nospam.com said:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
One problem
On 2010-12-10 21:28:43 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 12/10/10 6:25 PM, Michel Fortin wrote:
One problem I'm starting to realize is that we now have so many
available qualifiers for function parameters than it's really easy to
get lost.
In D1 it was simple:
On Sun, 05 Dec 2010 09:18:13 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/5/10 12:04 AM, Steven Schveighoffer wrote:
I'm totally confused. I thought the point of auto ref was to pass by
value if it's an rvalue (since the data is already on the stack). If
this is not
On Sat, 04 Dec 2010 23:36:22 -0500
Steven Schveighoffer schvei...@yahoo.com wrote:
No no no, inout does not belong here. Use const. inout is only used if
you are returning a portion of the arguments. That should be a hard rule
by the compiler (error).
Fixed:
bool opEquals(auto ref
Le 04/12/2010 10:00, Franciszek Czekala a écrit :
Anyway, if struct has value semantics then perhaps the argument to
opEquals should have simply 'in' mode? In Ada95 the 'in' mode of
the arguments does not determine how the arguments are passed
internally to the function. The compiler can choose
Huh? I don't think you understand what I mean. inout only implicitly
converts to const. Example:
struct S
{
bool opEquals(S rhs){return false;}
}
struct T
{
S s;
bool opEquals(auto ref inout T rhs) inout {
return s == rhs.s; // error, cannot call S.opEquals(S rhs) with
On 12/5/10 12:06 AM, Steven Schveighoffer wrote:
On Sun, 05 Dec 2010 00:42:20 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Yah, still not getting the original point there.
I responded better in another part of this thread.
Basically, inout doesn't mean what you think it
On 12/5/10 12:04 AM, Steven Schveighoffer wrote:
I'm totally confused. I thought the point of auto ref was to pass by
value if it's an rvalue (since the data is already on the stack). If
this is not the case, then why not just make ref work that way? Why
wouldn't I mark all my functions as auto
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
But this disallows comparisons with rvalues.
eg,
Foo bar() { Foo x = 1; return x; }
Foo y=1;
assert( y == bar() ); // doesn't compile
You can get around this by declaring a
On Sat, 4 Dec 2010 09:00:05 + (UTC)
Franciszek Czekala h...@valentimex.com wrote:
Anyway, if struct has value semantics then perhaps the argument to
opEquals should have simply 'in' mode? In Ada95 the 'in' mode of
the arguments does not determine how the arguments are passed
internally to
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand why they can't be already. C++ definitely allows
this. Is there something bad about it? I'd probably use const ref a lot more,
but because it will only
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand why they can't be already. C++ definitely
allows
this.
If you don't mean new C++ standards, this is not true. It is supported by
non-standard
I'm a bit uncertain as to how this is all supposed to work.
(1) Should temporaries be allowed to be passed as 'const ref'?
Rather, what keeps compiler from interpreting A fun() like const ref A
fun() when it is necessary?
After all D's const system has no holes in this case unlike C++.
--
On Saturday 04 December 2010 03:49:26 so wrote:
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand why they can't be already. C++ definitely
allows
this.
If you don't mean new C++ standards,
I'm 99.99% certain that it's perfectly legal to pass a temporary to a
function
that takes a const T and that it's in the standard
Oh that is right, but both are different things.
Say, when you have:
T fun() {...}
void bar(const T) {...}
bar(fun()) // 1. this is perfectly legal.
const T a =
I'm a bit uncertain as to how this is all supposed to work.
(1) Should temporaries be allowed to be passed as 'const ref'?
Oh... we are saying exact same thing but i interpreted passed as 'const
ref' out of the context!
I guess Jonathan also saying the same thing.
Sorry about that!
--
On 12/4/10 4:35 AM, Jonathan M Davis wrote:
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand why they can't be already. C++ definitely allows
this.
C++'s second biggest mistake.
Andrei
On 12/4/10 6:50 AM, so wrote:
I'm 99.99% certain that it's perfectly legal to pass a temporary to a
function
that takes a const T and that it's in the standard
Oh that is right, but both are different things.
Say, when you have:
T fun() {...}
void bar(const T) {...}
bar(fun()) // 1. this is
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs there should be no official
implementation of opEquals, opCmp etc. All the compiler needs to worry
about is to
On Saturday 04 December 2010 06:00:58 Andrei Alexandrescu wrote:
On 12/4/10 4:35 AM, Jonathan M Davis wrote:
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand why they can't be already. C++
On Sat, 04 Dec 2010 16:05:07 +0200, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 6:50 AM, so wrote:
I'm 99.99% certain that it's perfectly legal to pass a temporary to a
function
that takes a const T and that it's in the standard
Oh that is right, but both are
On 12/4/10 8:29 AM, Jonathan M Davis wrote:
On Saturday 04 December 2010 06:00:58 Andrei Alexandrescu wrote:
On 12/4/10 4:35 AM, Jonathan M Davis wrote:
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand
i would take take the address of a temporary function...
Should be:
i would take the address of a temporary object/value.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs there should be no official
implementation of opEquals, opCmp etc. All the compiler needs
Andrei, your explanation is almost the same as was my understanding. Thank you.
My shallow thought:
const T makes automatically reference. It is convenient.
Right thinking:
D has no semantics dividing copying/referencing, against has
dividing rvalue/lvalue.
D should support this like
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs there should be no official
implementation of opEquals,
bool opEquals(auto ref inout Tuple rhs) inout {
foreach (i, T; Types) {
if (this[i] != rhs[i]) return false;
}
return true;
}
It looks a bit alembicated but let's not forget that Tuple is supposed
to be very flexible and to do a lot of things.
Const-system is a one big
Keyword cocktails..
2010/12/4 so s...@so.do:
bool opEquals(auto ref inout Tuple rhs) inout {
foreach (i, T; Types) {
if (this[i] != rhs[i]) return false;
}
return true;
}
It looks a bit alembicated but let's not forget that Tuple is supposed to
be very flexible and to do a lot
Andrei Alexandrescu wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs there should be no official
On 12/4/10 2:39 PM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs
On Sat, 04 Dec 2010 11:00:58 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
On 12/4/10 22:42 CST, Steven Schveighoffer wrote:
On Sat, 04 Dec 2010 15:58:43 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 2:39 PM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
On 12/4/10 22:36 CST, Steven Schveighoffer wrote:
On Sat, 04 Dec 2010 11:00:58 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct
On 12/4/10 23:40 CST, Andrei Alexandrescu wrote:
Yah. Method calls are already passed by reference (I'd prefer not but
that's just me).
Sorry, I meant: method calls are already allowed for rvalues. Sleepy...
Andrei
On Sun, 05 Dec 2010 00:40:26 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 22:36 CST, Steven Schveighoffer wrote:
On Sat, 04 Dec 2010 11:00:58 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu
On Sun, 05 Dec 2010 00:42:20 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Yah, still not getting the original point there.
I responded better in another part of this thread.
Basically, inout doesn't mean what you think it means.
-Steve
69 matches
Mail list logo
