Re: rvalue references

On Wednesday, 24 April 2013 at 02:56:42 UTC, Jonathan M Davis wrote: So, probably the best route at this point is to come up with a new attribute which is replace with ref in the function definition and When you say "replace with ref", does that mean 'ref' won't appear in the common case? r

Re: rvalue references

On 4/23/2013 6:02 PM, Diggory wrote: Why does the temporary need to exist any longer than the current statement? And it doesn't in C++.

Re: rvalue references

On 4/23/2013 8:32 PM, Manu wrote: Is it actually complicated? It's a lot more complicated than simply destructing them at the end of a function. You have to define what happens for conditionally executed expressions || && ?:, what happens at the end of a statement, what happens at a }, what

Re: [ gtkD ] Question about mouse press event in Notebook ...

And sorry for bad ASCI sample ... You should copy it to your favorite text editor. Sorry ...

Re: [ gtkD ] Question about mouse press event in Notebook ...

Sorry, you don't understand me. I want something like this: /--Frameless Window--\ |*First Reordalable tab* | *Second ...* || Rest - drag this to begin move window | |*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

Re: DIP 36: Rvalue References

On Tuesday, 23 April 2013 at 18:41:07 UTC, Andrei Alexandrescu wrote: Making 'safe' ref the default is a major breaking change. How do you assess the size of the breakage? I think it's fairly well-understood, probably with the same meaning that you used in your own post somewhere else: ht

Re: Official D Grammar

On 2013-04-24 03:40, Jonathan M Davis wrote: That would mean creating more keywords, which would break code. By using @, we avoid having to create new keywords, which I believe was the whole point in the first place. Which attributes got @ on them was fairly arbitrary, but they do definitely ser

Re: rvalue references

On Wednesday, 24 April 2013 at 03:41:17 UTC, Manu wrote: scope ref a(scope ref int x) { return x; } One thing to bear in mind about this usage is that 'scope' could apply to the implicit 'this' reference, in addition to describing the return type, which might make it unfeasible. I don't know

Re: RES file not linking anymore with DMD v2.052

On 23.04.2013 09:48, Ettienne wrote: On Monday, 22 April 2013 at 22:19:39 UTC, Rainer Schuetze wrote: Yes, it should be fixed in the rc for the next version: http://www.dsource.org/projects/visuald/browser/downloads/VisualD-v0.3.36rc5.exe Hi Rainer, With VisualD-v0.3.36rc5 (Win XP 32bit,

Re: Twitter widget cut on dconf.org on Chrome/OSX

On 2013-04-24 01:42, Nick Sabalausky wrote: I consider HTML-tables-for-layout one of my not-so-secret weapons. It's immensely useful, simple, powerful and easy, they work right on freaking everything, and ever since PalmOS browsers disappeared (ie no nested tables) it has no real downsides aside

Re: rvalue references

On Tuesday, 23 April 2013 at 19:45:39 UTC, Zach the Mystic wrote: ref T func(ref T x, @noreturn ref T y) { return x; // pass return y; // error static T* t = &y; // pass!? } Sorry about the static definition. It should be: 'static T* t; t = &y;' instead, and for all subsequent definition

Re: D compile time algorithms implementation

But, I'm sorry, I do not have the ability to work with the code itself, now. I take a few other things. Regards, Khursid. Oh,god !!!

Re: DIP 36: Rvalue References

On Tuesday, 23 April 2013 at 08:13:28 UTC, Mehrdad wrote: On Wednesday, 10 April 2013 at 06:11:29 UTC, Zach the Mystic wrote: no value type is ever unsafe. Delegates? Well, I don't know the formal definition of a delegate, but I believe it is a pointer to a function, plus a pointer to a dat

Re: rvalue references

On Wednesday, 24 April 2013 at 04:41:47 UTC, Manu wrote: The issue is that in this case for instance, the temporary is conditionally created. Then cannot bind to the enclosing scope. Conditionally created, in the event you pass an rvalue or not? What about binding? I don't know what you're

Re: rvalue references

On 24 April 2013 14:07, deadalnix wrote: > On Wednesday, 24 April 2013 at 03:33:07 UTC, Manu wrote: > >> On 24 April 2013 04:44, Walter Bright wrote: >> >> On 4/23/2013 8:33 AM, Manu wrote: >>> >>> "The r-value being passed is assigned to a stack allocated temporary, which has a life

Re: rvalue references

On Wednesday, 24 April 2013 at 03:33:07 UTC, Manu wrote: On 24 April 2013 04:44, Walter Bright wrote: On 4/23/2013 8:33 AM, Manu wrote: "The r-value being passed is assigned to a stack allocated temporary, which has a lifetime that is identical to any other local variable, ie, the lifeti

Re: rvalue references

On 24 April 2013 11:22, kenji hara wrote: > Temporaries which created on stack to pass an address to `scope ref` > parameter would be destroyed after the "current statement/expression". > > T rvalue(); > > void foo(scope ref T) { ... } > foo(rvalue()); // here is "current statement/expression"

Re: rvalue references

> > > On 24 April 2013 11:02, Diggory wrote: > >> On Wednesday, 24 April 2013 at 00:54:12 UTC, kenji hara wrote: >> >>> 2013/4/24 Manu >>> >>> "The r-value being passed is assigned to a stack allocated temporary, which has a lifetime that is identical to any other local variable, ie, t

Re: rvalue references

scope ref a(scope ref int x) { return x; } void b(scope ref int x); On 24 April 2013 11:02, Diggory wrote: > On Wednesday, 24 April 2013 at 00:54:12 UTC, kenji hara wrote: > >> 2013/4/24 Manu >> >> "The r-value being passed is assigned to a stack allocated temporary, >>> which has a lifetime

Re: rvalue references

On 24 April 2013 04:44, Walter Bright wrote: > On 4/23/2013 8:33 AM, Manu wrote: > >> "The r-value being passed is assigned to a stack allocated temporary, >> which has >> a lifetime that is identical to any other local variable, ie, the >> lifetime of >> the function in which it appears." >> The

Re: rvalue references

On 24 April 2013 04:29, Andrei Alexandrescu wrote: > On 4/23/13 2:00 PM, Manu wrote: > >> On 24 April 2013 03:15, Andrei Alexandrescu >> > Many details are missing. This is not a simple problem. >> >> >> So what are some others? >> > > Returning a reference is an important topic. > I think t

Re: rvalue references

On Tuesday, April 23, 2013 14:58:50 Andrei Alexandrescu wrote: > On 4/23/13 2:45 PM, Namespace wrote: > >> auto ref is needed to accept rvalues. > > > > I'm curious as to when that is implemented. Or if I purely watch here > > again in a year and the issue still exists. :) > > It is implemented,

Re: Mixin bug / unhelpful behavior?

On Tuesday, 23 April 2013 at 23:25:11 UTC, bearophile wrote: Mixin templates are a relatively new feature and maybe that alias use case was not considered, or it was not regarded as important. What are your use cases of aliasing a mixing template? I'm going to post it in a new thread.

Re: Official D Grammar

On Wednesday, April 24, 2013 00:34:54 Diggory wrote: > If at some point custom attributes will be allowed, @ would be a > nice syntax for that. > > Things like @safe could be attributes implemented by the standard > library - would cut down on the number of keywords. We already have custom attrib

Re: Official D Grammar

On Tuesday, April 23, 2013 21:51:54 Stewart Gordon wrote: > Er, do away with the meaningless @? Since nobody seems to have > succeeded in explaining how the @-attributes differ from the rest, it > seems the right way to go. That would mean creating more keywords, which would break code. By using @

Re: rvalue references

Temporaries which created on stack to pass an address to `scope ref` parameter would be destroyed after the "current statement/expression". T rvalue(); void foo(scope ref T) { ... } foo(rvalue()); // here is "current statement/expression" // lowered to: { auto __tmp = rvalue(); foo(__tmp); __t

Re: rvalue references

On Wednesday, 24 April 2013 at 00:54:12 UTC, kenji hara wrote: 2013/4/24 Manu "The r-value being passed is assigned to a stack allocated temporary, which has a lifetime that is identical to any other local variable, ie, the lifetime of the function in which it appears." There, I defined it.

Re: rvalue references

2013/4/24 Manu > "The r-value being passed is assigned to a stack allocated temporary, > which has a lifetime that is identical to any other local variable, ie, the > lifetime of the function in which it appears." > There, I defined it. > Good definition. If add more, "getting address of "scope"

Re: DIP 36: Rvalue References

First of all, we should define words for the discussion. 1. Let's name current `auto ref` "parameterized-ref", which works only with template functions and the `auto ref` parameter is instantiated to both ref/non-ref by the actual function argument. 2. Let's call it "rvalue-ref(erence)", which cur

Re: A little Go => Python story

Sorry, the title of this thread should be "A little Python => Go story"... Bye, bearophile

Re: A little Go => Python story

Luís Marques: The only one that seems "easy" to solve in D is adding sets, no? Considering the troubles given by the built-in D associative arrays, and the possibility to write good enough set literals like: auto s1 = set([1, 10, 5]); // helper function. Set!int items = iota(2, 11)

Re: A little Go => Python story

On Tuesday, 23 April 2013 at 23:09:46 UTC, bearophile wrote: * If you're using JSON and your JSON is a mix of types, goood luck. You'll have to create a custom struct that matches the format of your JSON blob, and then Unmarshall the raw json into an instance of your custom struct. Much mo

Re: Stable D version?

On Tuesday, April 23, 2013 07:02:39 Mehrdad wrote: > Well, I think the float behavior is correct and the string > example is broken, but that wasn't my point anyway. > > The point was that it's still broken. According to TDPL (section 7.1.5.2, p. 258 - 259), == on structs should be equivalent to

Re: Twitter widget cut on dconf.org on Chrome/OSX

On Wed, 24 Apr 2013 00:40:44 +0200 "Vladimir Panteleev" wrote: > > (Alternatively, just use a table.) I consider HTML-tables-for-layout one of my not-so-secret weapons. It's immensely useful, simple, powerful and easy, they work right on freaking everything, and ever since PalmOS browsers disapp

Re: A little Go => Python story

Perhaps you should be able to use void[T] for a set...

Re: Mixin bug / unhelpful behavior?

Luís Marques: 1) Is it a bug that mixin_not_defined_bug does not produce a compile-time error, unless it is called? (DMD64 v2.062, OS X) I think that here D is working according to its current specs. On the other hand this topic was recently discussed and despite Andrei the consensus seems t

Re: A little Go => Python story

The only one that seems "easy" to solve in D is adding sets, no?

Mixin bug / unhelpful behavior?

Consider the following code: mixin template Bar() { void Bar() {}; } void mixin_ok() { mixin Bar; Bar(); } void mixin_not_defined_ok() { mixin UndefinedMixin; // OK, compile-time error } void mixin_not_defined_bug()()

A little Go => Python story

This blog post tells a short simple story of replacing Python with Go: http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/2013/04/23/ Probably the SVM code was already written in C, and just called from Python. I don't know if later they have rewritten the SVM

Re: Twitter widget cut on dconf.org on Chrome/OSX

On Tuesday, 23 April 2013 at 21:39:39 UTC, Andrei Alexandrescu wrote: Thanks, confirmed (comes to 641px in my browser). Problem is that constraint seems to be generated dynamically. http://dconf.org/includes/css.js This looks like a JS hack for the multi-column CSS problem (trying to have mul

Re: Official D Grammar

If at some point custom attributes will be allowed, @ would be a nice syntax for that. Things like @safe could be attributes implemented by the standard library - would cut down on the number of keywords.

Re: Twitter widget cut on dconf.org on Chrome/OSX

On 4/23/13 12:01 PM, qznc wrote: On Monday, 22 April 2013 at 15:57:28 UTC, Andrei Alexandrescu wrote: We have a bit of trouble with the Twitter widget on Chrome, at http://dconf.org/talks/lucarella.html. The widget is chopped at the bottom. Is there a simple fix for this? The element has a h

Re: Stable D version?

On Tuesday, 23 April 2013 at 20:21:55 UTC, eles wrote: On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu I was mainly referring to the fact that C++ succeeded in spite of having i

Re: Stable D version?

Am 23.04.2013 22:21, schrieb eles: On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu I was mainly referring to the fact that C++ succeeded in spite of having initially an incomple

Re: rvalue references

On 04/23/2013 10:44 PM, Andrei Alexandrescu wrote: On 4/23/13 4:24 PM, Timon Gehr wrote: On 04/23/2013 07:15 PM, Andrei Alexandrescu wrote: ... The justification is that unsafe uses of ref are few and uninteresting (they can be replaced with pointers). I don't get this. Uses cannot be "unsaf

Re: Official D Grammar

On 02/04/2013 03:13, Walter Bright wrote: On 4/1/2013 4:18 PM, Brian Schott wrote: 1) Grammar defined in terms of things that aren't tokens. Take, for example, PropertyDeclaration. It's defined as an "@" token followed by... what? "safe"? It's not a real token. It's an identifier. You can't pa

Re: rvalue references

On 4/23/13 4:24 PM, Timon Gehr wrote: On 04/23/2013 07:15 PM, Andrei Alexandrescu wrote: ... The justification is that unsafe uses of ref are few and uninteresting (they can be replaced with pointers). I don't get this. Uses cannot be "unsafe". They are either correct or wrong. Unfortunatel

Re: Stable D version?

On 04/23/2013 10:21 PM, eles wrote: On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu I was mainly referring to the fact that C++ succeeded in spite of having initially an incompl

Re: rvalue references

On 04/23/2013 07:15 PM, Andrei Alexandrescu wrote: ... The justification is that unsafe uses of ref are few and uninteresting (they can be replaced with pointers). I don't get this. Uses cannot be "unsafe". They are either correct or wrong. It would be very powerful to be able to guarantee t

Re: Stable D version?

On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu I was mainly referring to the fact that C++ succeeded in spite of having initially an incomplete specification. Nowadays the expe

Re: DIP 36: Rvalue References

On 04/23/2013 09:51 PM, Steven Schveighoffer wrote: On Tue, 23 Apr 2013 15:40:35 -0400, Timon Gehr wrote: Safety should be guaranteed in @safe code. There is no point in conservatively disallowing perfectly fine @system code on the basis of safety concerns, unless, of course, the type system

Re: DIP 36: Rvalue References

On Tue, 23 Apr 2013 15:40:35 -0400, Timon Gehr wrote: Safety should be guaranteed in @safe code. There is no point in conservatively disallowing perfectly fine @system code on the basis of safety concerns, unless, of course, the type system is advanced enough to prove safe all relevant us

Re: rvalue references

On Tuesday, 23 April 2013 at 03:30:35 UTC, Walter Bright wrote: Previous discussions: http://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com#post-4F84D6DD.5090405:40digitalmars.com http://d.puremagic.com/issues/show_bug.cgi?id=9238 This is of course an important issue. I don't know if

Re: DIP 36: Rvalue References

On 04/23/2013 07:33 PM, Andrei Alexandrescu wrote: On 4/23/13 12:04 PM, Manu wrote: On 24 April 2013 00:24, Andrei Alexandrescu mailto:seewebsiteforem...@erdani.org>> wrote: The very point of this DIP is to not create syntax-driven features, instead better define existing ones

Re: rvalue references

Based on DIP25/35 but slightly simplified, these rules would make "ref" safe, would minimise code breakage, and only marginally restricts the usage of "ref". The notion of "lifetime" is purely a tool for simplifying the explanation of the rules. Lifetimes 0 = temporary/rvalue 1 = local variabl

Re: rvalue references

On 4/23/13 3:01 PM, Namespace wrote: On Tuesday, 23 April 2013 at 18:58:50 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:45 PM, Namespace wrote: auto ref is needed to accept rvalues. I'm curious as to when that is implemented. Or if I purely watch here again in a year and the issue still exist

Re: rvalue references

On Tuesday, 23 April 2013 at 14:25:36 UTC, Andrei Alexandrescu wrote: Now, this may be too naive, but what about allowing the compiler to pass regular (not declared ref) const arguments per reference as it sees fit? It would be just another optimization. I'd declare function(const arg) and tha

Re: rvalue references

On Tuesday, 23 April 2013 at 18:58:50 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:45 PM, Namespace wrote: auto ref is needed to accept rvalues. I'm curious as to when that is implemented. Or if I purely watch here again in a year and the issue still exists. :) It is implemented, but curre

Re: Stable D version?

On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu wrote: I think we shouldn't follow the C++ model. Whatever made C++ successful is not what'll make D successful. The context and expectations are very different now. Andrei That's a pretty vague ass

Re: rvalue references

On 4/23/13 2:45 PM, Namespace wrote: auto ref is needed to accept rvalues. I'm curious as to when that is implemented. Or if I purely watch here again in a year and the issue still exists. :) It is implemented, but currently only for templates. Andrei

Re: rvalue references

auto ref is needed to accept rvalues. I'm curious as to when that is implemented. Or if I purely watch here again in a year and the issue still exists. :)

Re: rvalue references

On 4/23/2013 8:33 AM, Manu wrote: "The r-value being passed is assigned to a stack allocated temporary, which has a lifetime that is identical to any other local variable, ie, the lifetime of the function in which it appears." There, I defined it. Locals have a lifetime that is terminated by th

Re: DIP 36: Rvalue References

In that example you could make opOpAssign take a "const ref" and then the compiler could see that it could not return that parameter, but this is slightly hacky and I can see how there may be obscure corner cases where the rules are not sufficient. Actually this could also be solved by using

Re: Stable D version?

On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu wrote: I think we shouldn't follow the C++ model. Whatever made C++ successful is not what'll make D successful. The context and expectations are very different now. Andrei That's a pretty vague assertion. Please define the model

Re: DIP 36: Rvalue References

On 4/23/13 2:32 PM, Manu wrote: On 24 April 2013 04:01, Andrei Alexandrescu mailto:seewebsiteforem...@erdani.org>> wrote: On 4/23/13 1:57 PM, Steven Schveighoffer wrote: On Tue, 23 Apr 2013 13:33:31 -0400, Andrei Alexandrescu mailto:seewebsiteforem...@erdani.org>__> wrote:

Re: DIP 36: Rvalue References

On 4/23/13 2:29 PM, Manu wrote: On 24 April 2013 03:33, Andrei Alexandrescu mailto:seewebsiteforem...@erdani.org>> wrote: The best setup would be: 1. To take lvalues by reference, write "ref". 2. To take lvalues and rvalues by reference, write "auto ref". That's not a good setup a

Re: DIP 36: Rvalue References

On 24 April 2013 04:01, Andrei Alexandrescu wrote: > On 4/23/13 1:57 PM, Steven Schveighoffer wrote: > >> On Tue, 23 Apr 2013 13:33:31 -0400, Andrei Alexandrescu >> wrote: >> >> Our intent is to make "ref" always scoped and reserve non-scoped uses >>> to pointers. >>> >> >> So no more returning

Re: rvalue references

On 4/23/13 2:00 PM, Manu wrote: On 24 April 2013 03:15, Andrei Alexandrescu mailto:seewebsiteforem...@erdani.org>> wrote: "scope" is a keyword, not a language feature. In case you are referring to scope variables, the feature "scope ref" has little to do with it. How so? 'scope' sim

Re: [ gtkD ] Question about mouse press event in Notebook ...

On 04/23/2013 08:13 AM, Super66Super wrote: "The begingMoveDrag call in mousepressevent makes it so that you drag the window around when holding the left mouse on on of the tabs. And that prevents you from reordering the tabs." I understand, thanks for the valuable information. "What are you

Re: DIP 36: Rvalue References

On 24 April 2013 03:33, Andrei Alexandrescu wrote: > On 4/23/13 12:04 PM, Manu wrote: > >> On 24 April 2013 00:24, Andrei Alexandrescu >> > > >> >> >> wrote: >> >> >> The very point of this DIP is to not create >> syntax-driven features, ins

Re: DIP 36: Rvalue References

On Tue, 23 Apr 2013 14:01:14 -0400, Diggory wrote: So no more returning ref? Because if you allow returning ref, you lose any notion of safety, unless you plan on changing the entire compilation model? The rules from DIP25/35 show how you can return refs while still maintaining safety

Re: DIP 36: Rvalue References

So no more returning ref? Because if you allow returning ref, you lose any notion of safety, unless you plan on changing the entire compilation model? The rules from DIP25/35 show how you can return refs while still maintaining safety.

Re: DIP 36: Rvalue References

On 4/23/13 1:57 PM, Steven Schveighoffer wrote: On Tue, 23 Apr 2013 13:33:31 -0400, Andrei Alexandrescu wrote: Our intent is to make "ref" always scoped and reserve non-scoped uses to pointers. So no more returning ref? If we can't return ref, ref has failed. (This is what makes the entire

Re: rvalue references

On 4/23/13 1:53 PM, Dicebot wrote: On Tuesday, 23 April 2013 at 17:15:14 UTC, Andrei Alexandrescu wrote: DIP36 should be closed. We must focus on making ref safe and on making auto ref work with non-templates. It is marked as such already, since the very moment you have stated your opinion.

Re: rvalue references

On 24 April 2013 03:15, Andrei Alexandrescu wrote: > On 4/23/13 11:27 AM, Manu wrote: > >> On 24 April 2013 00:30, Andrei Alexandrescu >> > > >> >> >> wrote: >> >> On 4/23/13 10:05 AM, Manu wrote: >> >> I can't see the fault in DIP36's reasoning

Re: DIP 36: Rvalue References

On Tue, 23 Apr 2013 13:33:31 -0400, Andrei Alexandrescu wrote: Our intent is to make "ref" always scoped and reserve non-scoped uses to pointers. So no more returning ref? Because if you allow returning ref, you lose any notion of safety, unless you plan on changing the entire compilati

Re: rvalue references

On Tuesday, 23 April 2013 at 17:15:14 UTC, Andrei Alexandrescu wrote: DIP36 should be closed. We must focus on making ref safe and on making auto ref work with non-templates. It is marked as such already, since the very moment you have stated your opinion.

Re: DIP 36: Rvalue References

On 4/23/13 12:04 PM, Manu wrote: On 24 April 2013 00:24, Andrei Alexandrescu mailto:seewebsiteforem...@erdani.org>> wrote: The very point of this DIP is to not create syntax-driven features, instead better define existing ones that make sense on their own so they

Re: rvalue references

On 4/23/13 11:31 AM, Namespace wrote: That's on the mark. We need to make auto ref work with non-templates as well as templates, safely. The implementation mechanics may be different. Lifetime of temporaries is an important detail. I discuss such in http://d.puremagic.com/issues/show_bug.cgi?id=9

Re: rvalue references

On 4/23/13 11:27 AM, Manu wrote: On 24 April 2013 00:30, Andrei Alexandrescu mailto:seewebsiteforem...@erdani.org>> wrote: On 4/23/13 10:05 AM, Manu wrote: I can't see the fault in DIP36's reasoning. It just makes sense. Why is everyone so against it? I'm yet to unde

Re: rvalue references

On 4/23/13 10:38 AM, Dicebot wrote: On Tuesday, 23 April 2013 at 14:28:54 UTC, Andrei Alexandrescu wrote: If it were about scope it would be very careful with lifetime of temporaries. Andrei Please explain. In its current form DIP36 only cares that passed temporary exists while called functio

Re: rvalue references

No it is not the only difference. "scope ref" (as proposed in DIP35) is more restrictive in usage - can't take address of it, can't return it, can't implicitly cast it to normal ref. It is "scope" primarily and "rvalue ref solution" only secondarily. With DIP25 these restrictions apply to "ref

Re: DIP 36: Rvalue References

On 24 April 2013 00:24, Andrei Alexandrescu wrote: > >> The very point of this DIP is to not create >> syntax-driven features, instead better define existing ones that make >> sense on their own so they can be used for same purpose. >> > > It's a new feature, no two ways about it. It overlaps ref

Re: Twitter widget cut on dconf.org on Chrome/OSX

On Monday, 22 April 2013 at 15:57:28 UTC, Andrei Alexandrescu wrote: We have a bit of trouble with the Twitter widget on Chrome, at http://dconf.org/talks/lucarella.html. The widget is chopped at the bottom. Is there a simple fix for this? The element has a hard-coded height (643px). Remov

Re: rvalue references

That's on the mark. We need to make auto ref work with non-templates as well as templates, safely. The implementation mechanics may be different. Lifetime of temporaries is an important detail. I discuss such in http://d.puremagic.com/issues/show_bug.cgi?id=9238 but I never had the time to fin

Re: rvalue references

On 24 April 2013 01:01, deadalnix wrote: > On Tuesday, 23 April 2013 at 14:38:12 UTC, Dicebot wrote: > >> On Tuesday, 23 April 2013 at 14:28:54 UTC, Andrei Alexandrescu wrote: >> >>> If it were about scope it would be very careful with lifetime of >>> temporaries. >>> >>> Andrei >>> >> >> Please

Re: Twitter widget cut on dconf.org on Chrome/OSX

On Monday, 22 April 2013 at 17:11:49 UTC, Steven Schveighoffer wrote: On Mon, 22 Apr 2013 12:50:50 -0400, Mr. Anonymous wrote: A more serious issue is that the speakers page is chopped in Firefox: http://dconf.org/speakers/index.html It lists only until Dmitry Olshansky. No wonder, as it h

Re: rvalue references

On 24 April 2013 00:30, Andrei Alexandrescu wrote: > On 4/23/13 10:05 AM, Manu wrote: > >> I can't see the fault in DIP36's reasoning. It just makes sense. Why is >> everyone so against it? I'm yet to understand a reason... >> > > 1. It defines a new language feature instead of improving the exist

Re: Twitter widget cut on dconf.org on Chrome/OSX

On 2013-04-22 17:57, Andrei Alexandrescu wrote: We have a bit of trouble with the Twitter widget on Chrome, at http://dconf.org/talks/lucarella.html. The widget is chopped at the bottom. Is there a simple fix for this? There's something weird going on here. All browsers on Mac OS X has this p

Re: rvalue references

On Tuesday, 23 April 2013 at 14:38:12 UTC, Dicebot wrote: On Tuesday, 23 April 2013 at 14:28:54 UTC, Andrei Alexandrescu wrote: If it were about scope it would be very careful with lifetime of temporaries. Andrei Please explain. In its current form DIP36 only cares that passed temporary exi

Re: DIP 36: Rvalue References

On Tuesday, 23 April 2013 at 14:24:06 UTC, Andrei Alexandrescu wrote: On 4/23/13 4:08 AM, Dicebot wrote: You consider "scope" a new language feature? Yes. Well, ok, that explains everything. Thank you.

Re: rvalue references

On Tuesday, 23 April 2013 at 14:28:54 UTC, Andrei Alexandrescu wrote: If it were about scope it would be very careful with lifetime of temporaries. Andrei Please explain. In its current form DIP36 only cares that passed temporary exists while called function is executed. I can't imagine any

Re: rvalue references

On 4/23/13 10:05 AM, Manu wrote: I can't see the fault in DIP36's reasoning. It just makes sense. Why is everyone so against it? I'm yet to understand a reason... 1. It defines a new language feature instead of improving the existing ones. At this point in the development of the language, our

Re: rvalue references

On 4/23/13 6:39 AM, Dicebot wrote: On Tuesday, 23 April 2013 at 10:07:57 UTC, Namespace wrote: No it is not the only difference. "scope ref" (as proposed in DIP35) is more restrictive in usage - can't take address of it, can't return it, can't implicitly cast it to normal ref. It is "scope" prim

Re: Stable D version?

On 4/23/13 4:33 AM, eles wrote: On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote: On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote: I have raised this topic several times already. Stable version that is guaranteed to never break user code So what happens when a flaw in the la

Re: rvalue references

On 4/23/13 4:28 AM, anonymous wrote: On Tuesday, 23 April 2013 at 03:30:35 UTC, Walter Bright wrote: Previous discussions: http://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com#post-4F84D6DD.5090405:40digitalmars.com http://d.puremagic.com/issues/show_bug.cgi?id=9238 As far as I un

Re: DIP 36: Rvalue References

On 4/23/13 4:08 AM, Dicebot wrote: You consider "scope" a new language feature? Yes. And consider "auto ref" improvable solution. Yes. The very point of this DIP is to not create syntax-driven features, instead better define existing ones that make sense on their own so they can be used f

Re: rvalue references

On 4/23/13 3:07 AM, Namespace wrote: On Tuesday, 23 April 2013 at 03:30:35 UTC, Walter Bright wrote: Previous discussions: http://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com#post-4F84D6DD.5090405:40digitalmars.com http://d.puremagic.com/issues/show_bug.cgi?id=9238 I still like t

Re: rvalue references

On 23 April 2013 21:32, Timon Gehr wrote: > On 04/23/2013 09:07 AM, Namespace wrote: > >> On Tuesday, 23 April 2013 at 03:30:35 UTC, Walter Bright wrote: >> >>> Previous discussions: >>> >>> http://forum.dlang.org/thread/**4F84D6DD.5090405@digitalmars.** >>> com#post-4F84D6DD.5090405:**40digitalm

Re: rvalue references

On Tuesday, 23 April 2013 at 11:32:57 UTC, Timon Gehr wrote: On 04/23/2013 09:07 AM, Namespace wrote: On Tuesday, 23 April 2013 at 03:30:35 UTC, Walter Bright wrote: Previous discussions: http://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com#post-4F84D6DD.5090405:40digitalmars.com h

  1   2   >