Re: Stable D version?
On Tuesday, 23 April 2013 at 05:48:08 UTC, Chris Cain wrote: Incorrect. When I see a == b, I don't think anything. I stand corrected I guess. I'll stop thinking as well. It doesn't make sense to _you_. Okay sure, have fun watching people use languages that make more sense to them than D I guess. Is there something stopping you from defining opEquals for the behavior you want? yes, unnecessary waste of time/effort
Re: Stable D version?
On Tuesday, 23 April 2013 at 04:26:59 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote: ... Nope, still broken. The behavior isn't too surprising to me. Your code is buggy. You want to explain why the code is bugguy.
Re: Stable D version?
On Tuesday, 23 April 2013 at 05:57:16 UTC, Mehrdad wrote: I stand corrected I guess. I'll stop thinking as well. ... Okay sure, have fun watching people use languages that make more sense to them than D I guess. *sigh* I really wish you'd be more cooperative in this conversation. I certainly don't want to drive anyone away from D. I really don't understand why someone would say If you don't do what I want, I'm leaving! expecting to get their way, though. I'm trying to explain to you what's going on so that you can understand what is happening so that it will make sense to you. yes, unnecessary waste of time/effort Maybe use a tuple or Tuple instead then? Even easier and less time consuming than defining a struct.
Re: [ gtkD ] Question about mouse press event in Notebook ...
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 trying to achieve with mousepressevent? I want to: *have undecorated window with Notebook - ok, no problem *reorderable tabs - ok, no problem *begin move window when press on Notebook - I need that Can I check if the mouse is above a tab in Notebook with mouse move / motion event ? If I could do it, then I can put a condition that checks it and assigns a value to a Boolean variable. Thus, in the event of pressing the left mouse button I check this variable and dependent on this I can move a window or not.
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:10:00 UTC, deadalnix wrote: You want to explain why the code is bugguy. Sure. He didn't know the behavior of == on structs and didn't realize it tests for identity by default. Structs require an opEquals defined to differ from this behavior.
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:07:55 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 05:57:16 UTC, Mehrdad wrote: I stand corrected I guess. I'll stop thinking as well. ... Okay sure, have fun watching people use languages that make more sense to them than D I guess. *sigh* I really wish you'd be more cooperative in this conversation. I certainly don't want to drive anyone away from D. I really don't understand why someone would say If you don't do what I want, I'm leaving! expecting to get their way, though. That's not quite what I'm saying. I'm just trying to make a point, which I'll repeat below. I'm trying to explain to you what's going on so that you can understand what is happening so that it will make sense to you. The trouble is that you've already failed before you started. People hate C++ because it's unintuitive. I can spend all day telling you about why C++'s behavior in e.g. the Abrahams-Dimov example (look it up) is _TECHNICALLY_ the correct/expected behavior. But in the end of the day it just doesn't make sense. I might win the battle, but C++ has already lost the war. So my point is, whether or not you can convince me this behavior is correct (and you probably won't), it's not going to change whether people find D easy to use. There's a reason why no other popular language (that I know of) translates == into a bitwise comparison of structs. What do you think the reason might be?
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote: There's a reason why no other popular language (that I know of) translates == into a bitwise comparison of structs. What do you think the reason might be? I'm intrigued. Mind listing the languages? As far as popular languages are concerned, I'm only aware of C# having structs, but most languages don't have structs.
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:26:55 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote: There's a reason why no other popular language (that I know of) translates == into a bitwise comparison of structs. What do you think the reason might be? I'm intrigued. Mind listing the languages? As far as popular languages are concerned, I'm only aware of C# having structs, but most languages don't have structs. I guess C and C++ aren't even considered languages anymore.
Re: Stable D version?
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 04:58:30 UTC, anonymous wrote: For fast bitwise comparison there's the is operator. The == operator should be slow. See also http://d.puremagic.com/issues/show_bug.cgi?id=3789 Well okay. The docs will have to be updated for this issue if it's fixed. For instance: http://dlang.org/ctod.html#structcmp In any case, I stand by that if you have a particular definition of behavior, you should provide it instead of expecting it to just work. But I suppose using is is more appropriate for this type of behavior. But calling it broken is a bit too strong. OK let me sum this up, as you seem confused. Whatever you think == should do, it is broken. If we assume that == should check for equality, then : pragma(msg, S(a) == S(a.idup)); writeln(S(a) == S(a.idup)); writeln(S(+0.0) == S(-0.0)); Should all evaluate to true. If == stand for identity, then they must all be false. You see that whatever is the semantic of ==, it is not properly implemented right now. Now, as we use == for equality and is for identity in other places (slices and objects for instance) it make sense to use the same for struct. But that another topic, as the demonstrated behavior is wrong, whatever is the semantic of ==.
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:26:55 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote: There's a reason why no other popular language (that I know of) translates == into a bitwise comparison of structs. What do you think the reason might be? I'm intrigued. Mind listing the languages? As far as popular languages are concerned, I'm only aware of C# having structs, but most languages don't have structs. And don't forget Objective-C, Visual Basic (.NET), Matlab...
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:23:56 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 06:10:00 UTC, deadalnix wrote: You want to explain why the code is bugguy. Sure. He didn't know the behavior of == on structs and didn't realize it tests for identity by default. Structs require an opEquals defined to differ from this behavior. Ho yes, so please explain what is this behavior, I'd be pleased to know.
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
The trouble is that you've already failed before you started.
Also, I'm assuming that this means that you had no intention of
learning. That's kind of a poor position to be in, IMO. That
means that I can't help you because you don't want to be helped.
So, I can give you appropriate alternatives (such as tuple) but
you won't look at it and see Oh, jeez, that's actually what I've
been using structs for. (Or not, but I can't ever know that's
not what you're looking for if you're not going to even try).
And I can't suggest snippets like:
bool opEquals(T rhs) {
foreach(i, e; this.tupleof) {
if(!(e == rhs.tupleof[i]))
return false;
}
return true;
}
... Which you could use in a mixin to start building a framework
of behaviors you can add to _any_ struct to automatically get the
behavior you want. We also can't discuss adding this as an
attribute using the new attribute system and adding it to the
standard library which might be something cool.
No, we have to do it _your_ way and using _your_ understanding,
instead of cooperating and getting a better result that we can
both agree on.
All I'm saying is that structs are really basic for a reason.
They're something you _build_ on. If you don't want to build on
it (and you want something already somewhat built), you might be
better served using something that _is_ prebuilt. Or make your
own platform based on a struct (kinda like how tuples are
implemented) and solve it that way.
So many solutions to your problem, yet you've already decided
that changing the language is the only right way.
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:41:36 UTC, Chris Cain wrote: So many solutions to your problem, yet you've already decided that changing the language is the only right way. I'm just telling you that if no other language has done it, there's a reason behind it.
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:41:36 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote: The trouble is that you've already failed before you started. Also, I'm assuming that this means that you had no intention of learning. I could tell you the same thing, but it wouldn't get me anywhere. All I'm saying is that structs are really basic for a reason. They're something you _build_ on. Then they shouldn't define a behavior for == in the first place. No behavior is better than wrong behavior.
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:31:44 UTC, Mehrdad wrote: I guess C and C++ aren't even considered languages anymore. ? main.c:13:10: error: invalid operands to binary == (have ‘struct S’ and ‘struct S’) if(a == b) You can't use == in C on structs ... ?
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:50:08 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 06:31:44 UTC, Mehrdad wrote: I guess C and C++ aren't even considered languages anymore. ? main.c:13:10: error: invalid operands to binary == (have ‘struct S’ and ‘struct S’) if(a == b) You can't use == in C on structs ... ? Exactly -- when there is no correct behavior, they didn't try implementing one.
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:46:49 UTC, Mehrdad wrote: I could tell you the same thing, but it wouldn't get me anywhere. Alrighty, that's my sign to leave. Good luck Mehrdad.
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:52:03 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 06:46:49 UTC, Mehrdad wrote: I could tell you the same thing, but it wouldn't get me anywhere. Good luck Mehrdad. Same to you.
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
I still like the Idea of DIP 36 (http://wiki.dlang.org/DIP36)
with scope ref / in ref. On this link we have also collected
several other suggested syntaxes.
But maybe we should discuss first, if auto ref could work for
non-templates.
This would mean that
1. auto ref generate code bloat for non-templates (doubled the
function 2^n times)
or
2. auto ref works like scope ref would do (create a temporary
lvalue and pass this to the function). But that would mean that
auto ref work differently for templates and non-templates (maybe
a problem?). If we choose this we should also discuss about the
lifetime of the temporary:
foo(auto ref A a) { }
foo(A());
// should then converted to
{
A __temp = A();
foo(__temp); // after this, __temp is destroyed
}
or
3. the compiler choose if an argument should be passed by ref, by
value or should be moved.
For example:
A a = A(42);
foo(a); // by ref
foo(A(23)); // move
Re: Stable D version?
On Tuesday, 23 April 2013 at 06:54:07 UTC, Mehrdad wrote: Same to you. I'm going to just be a little frank with you here. I've _never_ had even a slightly productive conversation with you. You're hostile to work with. I know you have some valuable things to say and contribute to the community, but its just too difficult to work with you. If you'd make some effort at being less antagonistic, you'd find you'd get much further. Like I said in my previous large post, there are solutions out there we could talk about, but you won't hear it. Heck, you essentially didn't even acknowledge the vast majority of what I had to say in my last large post. I had plenty of neat potential solutions, but they don't even get a slight consideration on your part. What a waste of time. I half-way expect a quick backhanded reply in less than 30 seconds yet again, but I hope you consider thinking about it over night.
Re: rvalue references
I'd still like someone to explain how exactly scope ref would differ from ref if DIP25/DIP35 were implemented. If the only difference is that scope ref can accept rvalues then why would you ever use normal ref? There are no extra restrictions needed on scope ref over and above normal ref under the assumption of DIP25/DIP35.
Re: Stable D version?
On Tuesday, 23 April 2013 at 07:09:41 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 06:54:07 UTC, Mehrdad wrote: Same to you. I'm going to just be a little frank with you here. I've _never_ had even a slightly productive conversation with you. You're hostile to work with. I know you have some valuable things to say and contribute to the community, but its just too difficult to work with you. Sorry, most of my responses are really short because I'm working on other things at the moment. I'm just trying to say a few sentences to make a point and go back to what I'm doing, but it's not going as well as I would have hoped. If you'd make some effort at being less antagonistic, you'd find you'd get much further. Like I said in my previous large post, there are solutions out there we could talk about, but you won't hear it. It's because you're solving a different problem than the one I'm mentioning. I'm telling you the problem (struct == behavior is wrong), you're telling me there is a workaround (tuples). I'm not looking for a workaround, I already know enough workarounds for it. I'm just trying to tell you it's a _workaround_ to a _problem_. The fact that it exists doesn't make the problem go away. Heck, you essentially didn't even acknowledge the vast majority of what I had to say in my last large post. Honestly, out of all the things I said, you also picked and chose single one to give nonsensical replies to. I said C and C++ and VB.NET and Matlab etc., and you just replied with C struct doesn't even have ==. Not only did you completely miss my first point there (why aren't other languages doing the same thing?), you also missed my second point: If == doesn't make sense, it shouldn't be defined at all. I had plenty of neat potential solutions, but they don't even get a slight consideration on your part. What a waste of time. Again, my purpose in mentioning this wasn't to look for a workaround, but to point out the problem itself, see above. I'm not having trouble finding workarounds, I'm just pointing out examples of why people aren't finding D usable (or why they consider it broken).
Re: Stable D version?
On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote: I'm not having trouble finding workarounds, I'm just pointing out examples of why people aren't finding D usable (or why they consider it broken). And I know no one likes to hear something is broken. I'm not doing that to be mean or something like that, I'm doing it because when I see people forget there are usability issues in D, I think it's beneficial for me to point out [you can correct me if I'm wrong] the flaws, rather than pretend that the language is very usable and people are just too slow in adopting it.
Re: Stable D version?
On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote: Sorry, most of my responses are really short because I'm working on other things at the moment. I'm just trying to say a few sentences to make a point and go back to what I'm doing, but it's not going as well as I would have hoped. OK. On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote: Honestly, out of all the things I said, you also picked and chose single one to give nonsensical replies to. I said C and C++ and VB.NET and Matlab etc., and you just replied with C struct doesn't even have ==. I'm just replying to this because I wanted to make it clear what I did: I booted up a Linux VM and wrote a quick program to try to understand where you were coming from, taking a painstaking effort to try to understand you and the context of what you're trying to say. I didn't respond to all of the other languages because I was immediately confused by the result of the first and, additionally, trying all of the above languages would be fairly time consuming. My apologies for not trying all of them. My intention was for good when I did it, so I hope that's enough to earn forgiveness for picking and choosing a single one to give nonsensical replies to. :-\ Not only did you completely miss my first point there (why aren't other languages doing the same thing?), you also missed my second point: If == doesn't make sense, it shouldn't be defined at all. Also, your second point wasn't missed. It simply didn't exist before I had started trying the C code. TBH, I think this would be a better solution. But I'd bet it'd break way too much code now.
Re: Stable D version?
On Tuesday, 23 April 2013 at 07:37:29 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote: Sorry, most of my responses are really short because I'm working on other things at the moment. I'm just trying to say a few sentences to make a point and go back to what I'm doing, but it's not going as well as I would have hoped. OK. On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote: Honestly, out of all the things I said, you also picked and chose single one to give nonsensical replies to. I said C and C++ and VB.NET and Matlab etc., and you just replied with C struct doesn't even have ==. I'm just replying to this because I wanted to make it clear what I did: I booted up a Linux VM and wrote a quick program to try to understand where you were coming from, taking a painstaking effort to try to understand you and the context of what you're trying to say. I didn't respond to all of the other languages because I was immediately confused by the result of the first and, additionally, trying all of the above languages would be fairly time consuming. My apologies for not trying all of them. My intention was for good when I did it, so I hope that's enough to earn forgiveness for picking and choosing a single one to give nonsensical replies to. :-\ Haha okay no worries, sorry my replies weren't terribly friendly. Btw there's www.ideone.com, you can also try some things there. Not only did you completely miss my first point there (why aren't other languages doing the same thing?), you also missed my second point: If == doesn't make sense, it shouldn't be defined at all. Also, your second point wasn't missed. It simply didn't exist before I had started trying the C code. Sorry I didn't realize that. :( Hope it makes sense now. TBH, I think this would be a better solution. But I'd bet it'd break way too much code now. I think if D wants to go anywhere, code will have to be broken, lots of it. No one's going to like it, but when it has broken features to begin with then it's not going to go very far in terms of usability.
Re: Stable D version?
On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote: On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote: On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote: What's holding you from releasing a version now and declaring it stable for e.g. a year? What would be the benefit of just declaring one release stable? This is not a trick question. That would not be a benefit, maybe. But, however, an answer to the question: will EVER D be finished? would be more than wonderful. Clean up the doubtful or wrong features and let it as it is. Further language improvements should be made after several years of use. Much like C++ is evolving with its standards, also C (C89, C99 etc.) Seriously, now, D is in the making for a decade and more. And, until it gets stable and Walter STOPS working on D (language) and, instead, only works on the COMPILER, things are not done. D starts looking like the D in _D_uke Nukem Forever (and forever it will take...). I got old looking at D and hoping that it will ever get released. Imagine that Bjarne Stroustrup would proceed today with changing C++ at the same pace as D is. C++ still evolves, albeit less fast than D, but also with much more scrutinity and, let's say, conservatorism. Which, after a while, it is good. Will D remain the forever unborn child of the programming languages? Born it. Let it become what is intended to be: a MATURE language. Yes, it might not grow perfect, but it will grow. It needs to get into childhood, enough with the (pro-)creation. At my job I went back to C++. With a language contunously in the making, the tools will never mature enough, never will get Eclipse plugins as good as CDT, never etc. I have that feeling (correct me if I am wrong) that C++ will catch up with D in several years. Look at C++11, it is a nice improvement. C++14 will be (hopefully) even better. And, then?... RadonsMinayev made a good decision to quit D back then and never look behind. A toy it was, a toy remained. I don't think my boss I have to know if D is finished to let us adopt it for future products, he only want to know we'll able to create our next product with D with the same requirement and if the delay will be the same or better. For the moment due to our target platform the response is no. But if we target only Desktops the answer seems to be really close to a yes. Some libraries are missing, but there is nothing we aren't capable to write. The major issue for a boss is to accept to move old c++ code to trash, that was his investment, actually because there is no D developers on job market, D code isn't valuable for him. To break the vicious circle some companies have to take the risk to migrate to D and let the world know it. The easier way for a language to be inserted in companies is certainly as scripting language, just like python. Because companies doesn't consider script as really pieces of software and let developers send it to trash. It's a mistake to not considering scripts as valuable just because they are not sell.
Re: rvalue references
On Tuesday, 23 April 2013 at 07:18:41 UTC, Diggory wrote: I'd still like someone to explain how exactly scope ref would differ from ref if DIP25/DIP35 were implemented. If the only difference is that scope ref can accept rvalues then why would you ever use normal ref? There are no extra restrictions needed on scope ref over and above normal ref under the assumption of DIP25/DIP35. 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.
Re: RES file not linking anymore with DMD v2.052
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, VS 2008) I get an install error: Error loading C:\Program Files\VisualD\visuald.dll. Invalid access to memory location I tried also with VisualD-v0.3.36rc4 - but get the same error. If I re-install VisualD-v0.3.35 it installs fine. Regards, Ettienne
Re: rvalue references
On Tuesday, 23 April 2013 at 07:45:41 UTC, Dicebot wrote: ... Ah, beg my pardon, I though it is yet another misunderstanding about DIP36.
Re: Stable D version?
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote: On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote: What's holding you from releasing a version now and declaring it stable for e.g. a year? What would be the benefit of just declaring one release stable? This is not a trick question. David I have raised this topic several times already. Stable version that is guaranteed to never break user code but still receives non-breaking bug-fixes is important for corporate adoption - those will never agree to spend some tome in the middle of running project to fix some unknown breakage created by a tool.
Re: Stable D version?
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 language is fixed? Do you fix it and break code, or do you leave it broken?
Re: DIP 36: Rvalue References
On Monday, 22 April 2013 at 20:02:12 UTC, Andrei Alexandrescu wrote: In a way I wish my not being polite would be the main bottleneck for this. I've been extremely busy at work, then preparing for DConf 2013, and last week has been quite distracting what with the Boston bombings three miles away from where we live and all that. It strikes me as odd to be obligated to spend time on something just because someone else did, and framed as impolite if I don't. Thanks for your time. Sometimes even simple Have seen it, will answer later / after DConf is priceless. That being said, I have made a pass through this DIP and I have the following concerns about it. 1. It defines a new language feature instead of improving the existing ones. At this point in the development of the language, our preference should be putting the existing features in good order. You consider scope a new language feature? And consider auto ref improvable solution. 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. 2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects. It can't because lifetime of temporaries is not defined in D at all and suck stuff needs to be consistent. It is not really different from a lifetime of struct literal temporary used for pass-by-value. 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role. auto ref is a template-world entity. If by improved you mean completely reworked than sure, I can add this rationale. Will do today. 4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to ref and to make auto ref work as a reference that can bind to rvalues as well as lvalues. Can't agree. scope is defined (but not implemented, a pity). Creating temporaries already exists for some cases. No really new language feature is added. No special syntax created. scope ref is still scope and ref with all semantics this imposes, rvalue references are just a side-effect. Contrary to this, auto ref IS a new feature created specifically for syntax hack. That is a very problem you are speaking about - introducing new concepts instead of making use of ones that exist for ages.
Re: DIP 36: Rvalue References
On Sunday, 21 April 2013 at 22:16:14 UTC, Timon Gehr wrote: Passing an r-value by ref is disallowed for arbitrary reasons. Reasons not closely related to lack of 'scope'. So why bind the new rule to scope? I had quite an impression this was prohibited mostly because of @safe issues.
Re: DIP 36: Rvalue References
On Sunday, 21 April 2013 at 16:08:55 UTC, Zach the Mystic wrote:
The only thing I could think of was if you want to 'ref' a
reference type.
void func(ref Object o, scope Object o2, scope ref Object o3) {}
Would there be a difference between the type of o and o2, or of
o2 and o3? There is inconsistency, but it would be nice to find
use cases which make this inconsistency truly unworkable with
other things in the language.
Taking consistent approach with ref, they all should have same
type but bpth ref and scope differences are mangled into func
name so that caller can take notion of proper behavior. I don't
see an issue here.
Re: Stable D version?
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 language is fixed? Do you fix it and break code, or do you leave it broken? Well we have 2.062 . Let's decide this is stable version. 2.062.1 will go out then 2.062.2, etc . . . They contains only fixes with really small (I mean almost non existent) breakage, no new feature, only fix of ICE, codegen bugs, etc . . . And 2.063 can still be pushed in the meantime. The thing that with D, you hit compiler bugs and so on, and you can't get fixes without getting the new version that break half of your code.
Re: DIP 36: Rvalue References
On Wednesday, 10 April 2013 at 06:11:29 UTC, Zach the Mystic wrote: no value type is ever unsafe. Delegates?
Re: Stable D version?
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 language is fixed? Do you fix it and break code, or do you leave it broken? Fix it in latest version. Leave it broken in stable.
Re: DIP 36: Rvalue References
On Wednesday, 10 April 2013 at 07:39:25 UTC, Zach the Mystic
wrote:
...
Kind of. I am thinking that scope is best when transitive for
aggregation but not for indirection:
struct S { int a; int *b; }
void foo(scope S s)
{
static int *x1 = (s.a); // error
static int *x2 = s.b; // fine
}
Re: Stable D version?
On Tuesday, 23 April 2013 at 08:18:08 UTC, Dicebot 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 language is fixed? Do you fix it and break code, or do you leave it broken? Fix it in latest version. Leave it broken in stable. I'm not convinced that's terribly useful but if you think so then ok...
Re: DIP 36: Rvalue References
On 04/23/2013 10:10 AM, Dicebot wrote: On Sunday, 21 April 2013 at 22:16:14 UTC, Timon Gehr wrote: Passing an r-value by ref is disallowed for arbitrary reasons. Reasons not closely related to lack of 'scope'. So why bind the new rule to scope? I had quite an impression this was prohibited mostly because of @safe issues. It is disallowed in @system code.
Re: Stable D version?
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote: On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote: On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote: What's holding you from releasing a version now and declaring it stable for e.g. a year? What would be the benefit of just declaring one release stable? This is not a trick question. David I have raised this topic several times already. Stable version that is guaranteed to never break user code but still receives non-breaking bug-fixes is important for corporate adoption - those will never agree to spend some tome in the middle of running project to fix some unknown breakage created by a tool. Okay, maybe it was somewhat of a trick question after all: Tourist put it as if all that was required was to mark a certain version stable, and I wanted to hint at the fact that this alone wouldn't help anybody at all. David
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 As far as I understand the usability disaster of disallowing rvalue references is that I have to define a non-ref overload forwarding to my function(ref arg). That ref can't be for functionality, because I'm expecting references to rvalues/temporaries. = ref is merely for performance, and the parameter can be const. 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 that would be it.
Re: DIP 36: Rvalue References
On 04/23/2013 10:16 AM, Dicebot wrote:
On Wednesday, 10 April 2013 at 07:39:25 UTC, Zach the Mystic wrote:
...
Kind of. I am thinking that scope is best when transitive for
aggregation but not for indirection:
struct S { int a; int *b; }
void foo(scope S s)
{
static int *x1 = (s.a); // error
static int *x2 = s.b; // fine
}
(Both of these are in error because static variables are initialized at
compile time, but I get what you mean.)
Why would 'scope' have any effect on the validity of the first? s.a
belongs to the callee exclusively. Adding modular annotations to prevent
taking its address has no point.
Re: Stable D version?
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 language is fixed? Do you fix it and break code, or do you leave it broken? I am more for following the C/C++ solution: periodical revise the language, but not every two months. Several years and once that the compiler infrastructure is already in place and tested, publish (officially) the new version. During the meantime, users could live with workarounds and forbidden to do that!. Look at C and MISRA-C. It won't help to declare a stable version of D, while keep adding new things. What would really help is to stop adding new things, remove those that we are in doubt if they are good or no (properties?) or, at least, leave them as they are, then move towards improving the tools. A cleaner language with better tools will allow D to take off, while still leaving room for possible improvements in future revisions. C++ did not start as a perfect language, nor it has become, still there are tools for it, people are using it, companies are hiring C++ developers. Being predictable does matter sometimes. Tools matter too.
Re: DIP 36: Rvalue References
On Tuesday, 23 April 2013 at 08:19:43 UTC, Timon Gehr wrote: It is disallowed in @system code. Ye, I know and always took it as yet another we care mostly for @safe issue. What is the real rationale for this restriction?
Re: DIP 36: Rvalue References
On Tuesday, 23 April 2013 at 08:25:18 UTC, Timon Gehr wrote: (Both of these are in error because static variables are initialized at compile time, but I get what you mean.) Shame on me! (blush) Why would 'scope' have any effect on the validity of the first? s.a belongs to the callee exclusively. Adding modular annotations to prevent taking its address has no point. Because it is an attempt to take/store address of a scope variable, which is prohibited by scope definition. I think (but I am not sure!) that it makes sense to make scope transitive for aggregation, because automatic destruction upon leaving the scope happens for aggregated entities. Thus, nothing can be known about s.a lifetime, same as s lifetime. This is one step towards consistent scope behavior that will allow safety desired by this DIP.
Re: Stable D version?
On Tuesday, 23 April 2013 at 08:23:34 UTC, David Nadlinger wrote: Okay, maybe it was somewhat of a trick question after all: Tourist put it as if all that was required was to mark a certain version stable, and I wanted to hint at the fact that this alone wouldn't help anybody at all. David Sure. If naming is only thing required, than anyone can name it and no D team effort is needed :) Unfortunately, it is not that simple.
Re: D compile time algorithms implementation
On Monday, 22 April 2013 at 15:01:26 UTC, Andrei Alexandrescu wrote: On 4/20/13 8:41 AM, khurshid wrote: I wanted to say NoDuplicates )) I'd say let's add bug reports (either for library, compiler, or both) for each of these instances, and post pull requests appropriately. Thanks, Andrei Thanks for suggestion. 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.
Re: rvalue references
On Tuesday, 23 April 2013 at 07:18:41 UTC, Diggory wrote: I'd still like someone to explain how exactly scope ref would differ from ref if DIP25/DIP35 were implemented. If the only difference is that scope ref can accept rvalues then why would you ever use normal ref? There are no extra restrictions needed on scope ref over and above normal ref under the assumption of DIP25/DIP35. DIP25 imposes a number of code-breaking restrictions even in @system code, if DIP36 was in place, one could consider imposing the DIP25 restrictions only in SafeD. Furthermore if one day the compiler would be sufficiently smart to infer scope automatically, there still would be an important difference between 'ref' and 'scope ref'. ref rvalue ref would only work if the compiler succeeds in inferring scope, it could take a conservative approach to make sure it always err:s in the harmless direction... i.e. any '' or any asm block is an automatic failure. scope ref Works unless the compiler can prove it wrong(also usable from SafeD if marked with @trusted).
Re: Stable D version?
It is simply impossible for D. Defining trait for C/C++ is very strict and formal standard paper which completely defines the language. Revise of standard is decoupled with compiler releases. Standard can be revised once in a 10 years but compilers keep evolving having this paper in mind. D has reference compiler and thus you technically suggest to stop releasing any compiler version for 1-2 years. Ugh. On Tuesday, 23 April 2013 at 08:33:05 UTC, eles wrote: I am more for following the C/C++ solution: periodical revise the language, but not every two months. Several years and once that the compiler infrastructure is already in place and tested, publish (officially) the new version. During the meantime, users could live with workarounds and forbidden to do that!. Look at C and MISRA-C. It won't help to declare a stable version of D, while keep adding new things. What would really help is to stop adding new things, remove those that we are in doubt if they are good or no (properties?) or, at least, leave them as they are, then move towards improving the tools. A cleaner language with better tools will allow D to take off, while still leaving room for possible improvements in future revisions. C++ did not start as a perfect language, nor it has become, still there are tools for it, people are using it, companies are hiring C++ developers. Being predictable does matter sometimes. Tools matter too.
Re: Stable D version?
On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote: D has reference compiler and thus you technically suggest to stop releasing any compiler version for 1-2 years. Ugh. No. Stop adding things. Besides that, what's the alternative?
Re: rvalue references
On Tuesday, 23 April 2013 at 08:41:16 UTC, Tove wrote: DIP25 imposes a number of code-breaking restrictions even in @system code, if DIP36 was in place, one could consider imposing the DIP25 restrictions only in SafeD. Furthermore if one day the compiler would be sufficiently smart to infer scope automatically, there still would be an important difference between 'ref' and 'scope ref'. That is the important issue to solve. Many solution can jeopardize DIP36, which is why it must be delayed. Usually conflating issue in adhoc solution ends up in crap that must be sorted out later.
Re: Stable D version?
On 23 April 2013 09:56, eles e...@eles.com wrote: On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote: D has reference compiler and thus you technically suggest to stop releasing any compiler version for 1-2 years. Ugh. No. Stop adding things. Besides that, what's the alternative? Adding things isn't a problem and does not affect already existing code. Perhaps you meant changing behaviours and removing things? -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Stable D version?
On Tuesday, 23 April 2013 at 09:23:50 UTC, Iain Buclaw wrote: On 23 April 2013 09:56, eles e...@eles.com wrote: On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote: D has reference compiler and thus you technically suggest to stop releasing any compiler version for 1-2 years. Ugh. No. Stop adding things. Besides that, what's the alternative? Adding things isn't a problem and does not affect already existing code. Perhaps you meant changing behaviours and removing things? Any addition in D can be breaking wconsidering feature like is(typeof(blah))
Re: rvalue references
On Tuesday, 23 April 2013 at 09:06:52 UTC, deadalnix wrote: On Tuesday, 23 April 2013 at 08:41:16 UTC, Tove wrote: DIP25 imposes a number of code-breaking restrictions even in @system code, if DIP36 was in place, one could consider imposing the DIP25 restrictions only in SafeD. Furthermore if one day the compiler would be sufficiently smart to infer scope automatically, there still would be an important difference between 'ref' and 'scope ref'. That is the important issue to solve. Many solution can jeopardize DIP36, which is why it must be delayed. Usually conflating issue in adhoc solution ends up in crap that must be sorted out later. I see it as a future proof feature, not an issue. You want it to be a difference, so you can override the default compiler behavior.
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. My initial reason was to solve the rvalue ref issue. So it is completly inverse for me. :-)
Codegen, D, scope and priorities
This is an interesting improvement: http://d.puremagic.com/issues/show_bug.cgi?id=9963 But I think we have also to think about priorities. I think people interested in D performance today use GDC or LDC, and they avoid DMD. And maybe this is not going to change. On the other hand if D misses some of its parts then all D users are affected. So isn't it more important for Walter to use his time (this is just an example) to define the exact semantics of scope keyword and to implement it, instead of optimizing small operations done by the DMD compiler? When is scope going to be worked on? (And even regarding just bugs, I think Issue 3789 is one hundred times more important and urgent than Issue 9963.) Bye, bearophile
Re: Stable D version?
On Tuesday, 23 April 2013 at 08:56:37 UTC, eles wrote: On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote: D has reference compiler and thus you technically suggest to stop releasing any compiler version for 1-2 years. Ugh. No. Stop adding things. Besides that, what's the alternative? We don't have formal spec. Bug-fixing changes can't be differentiated from new changes. My ancient proposal is still in the newsgroup : http://forum.dlang.org/post/nchvayzsbrzevvucm...@forum.dlang.org
Re: rvalue references
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 primarily and rvalue ref solution only secondarily. My initial reason was to solve the rvalue ref issue. So it is completly inverse for me. :-) And I initially ignored all the threads you have started until noticed proposal that looked fundamental enough in its nature. :) Features created to support one specific use case usually are not worth it. DIP36 as far as I see it is much more about scope than about rvalues.
Re: rvalue references
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 http://d.puremagic.com/issues/show_bug.cgi?id=9238 I still like the Idea of DIP 36 (http://wiki.dlang.org/DIP36) with scope ref / in ref. ... That's fine. I don't.
Re: Stable D version?
On Tuesday, 23 April 2013 at 07:43:21 UTC, Flamaros wrote: On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote: On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote: On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote: What's holding you from releasing a version now and declaring it stable for e.g. a year? What would be the benefit of just declaring one release stable? This is not a trick question. That would not be a benefit, maybe. But, however, an answer to the question: will EVER D be finished? would be more than wonderful. Clean up the doubtful or wrong features and let it as it is. Further language improvements should be made after several years of use. Much like C++ is evolving with its standards, also C (C89, C99 etc.) Seriously, now, D is in the making for a decade and more. And, until it gets stable and Walter STOPS working on D (language) and, instead, only works on the COMPILER, things are not done. D starts looking like the D in _D_uke Nukem Forever (and forever it will take...). I got old looking at D and hoping that it will ever get released. Imagine that Bjarne Stroustrup would proceed today with changing C++ at the same pace as D is. C++ still evolves, albeit less fast than D, but also with much more scrutinity and, let's say, conservatorism. Which, after a while, it is good. Will D remain the forever unborn child of the programming languages? Born it. Let it become what is intended to be: a MATURE language. Yes, it might not grow perfect, but it will grow. It needs to get into childhood, enough with the (pro-)creation. At my job I went back to C++. With a language contunously in the making, the tools will never mature enough, never will get Eclipse plugins as good as CDT, never etc. I have that feeling (correct me if I am wrong) that C++ will catch up with D in several years. Look at C++11, it is a nice improvement. C++14 will be (hopefully) even better. And, then?... RadonsMinayev made a good decision to quit D back then and never look behind. A toy it was, a toy remained. I don't think my boss I have to know if D is finished to let us adopt it for future products, he only want to know we'll able to create our next product with D with the same requirement and if the delay will be the same or better. For the moment due to our target platform the response is no. But if we target only Desktops the answer seems to be really close to a yes. Some libraries are missing, but there is nothing we aren't capable to write. The major issue for a boss is to accept to move old c++ code to trash, that was his investment, actually because there is no D developers on job market, D code isn't valuable for him. To break the vicious circle some companies have to take the risk to migrate to D and let the world know it. The easier way for a language to be inserted in companies is certainly as scripting language, just like python. Because companies doesn't consider script as really pieces of software and let developers send it to trash. It's a mistake to not considering scripts as valuable just because they are not sell. The hardest selling point for systems programming languages is to get them adopted by an OS vendor, until then they are just another tool for business applications, a field already too crowded nowadays. Look at C++, only in the last decade did OS vendors start coding operating systems in C++, instead of plain C, to the point that C is now considered legacy at Microsoft. Who knows how long it will take for another vendor to pick up D for such use cases, even if it was 100% stable today? These things take a long time, even programmer generations. -- Paulo
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 http://d.puremagic.com/issues/show_bug.cgi?id=9238 I still like the Idea of DIP 36 (http://wiki.dlang.org/DIP36) with scope ref / in ref. ... That's fine. I don't. That's fine too. :)
Re: rvalue references
On 23 April 2013 21:32, Timon Gehr timon.g...@gmx.ch 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:**40digitalmars.comhttp://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com#post-4F84D6DD.5090405:40digitalmars.com http://d.puremagic.com/issues/**show_bug.cgi?id=9238http://d.puremagic.com/issues/show_bug.cgi?id=9238 I still like the Idea of DIP 36 (http://wiki.dlang.org/DIP36) with scope ref / in ref. ... That's fine. I don't. Can you suggest a superior/more sensible approach? 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...
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 the Idea of DIP 36 (http://wiki.dlang.org/DIP36) with scope
ref / in ref. On this link we have also collected several other
suggested syntaxes.
But maybe we should discuss first, if auto ref could work for
non-templates.
This would mean that
1. auto ref generate code bloat for non-templates (doubled the function
2^n times)
or
2. auto ref works like scope ref would do (create a temporary lvalue and
pass this to the function). But that would mean that auto ref work
differently for templates and non-templates (maybe a problem?). If we
choose this we should also discuss about the lifetime of the temporary:
foo(auto ref A a) { }
foo(A());
// should then converted to
{
A __temp = A();
foo(__temp); // after this, __temp is destroyed
}
or
3. the compiler choose if an argument should be passed by ref, by value
or should be moved.
For example:
A a = A(42);
foo(a); // by ref
foo(A(23)); // move
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 finish it.
Andrei
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 for same purpose. It's a new feature, no two ways about it. It overlaps ref and auto ref without any palpable benefit and defines yet another way to achieve the same thing as auto ref. On this ground alone the proposal has a large problem. 2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects. It can't because lifetime of temporaries is not defined in D at all and suck stuff needs to be consistent. It is not really different from a lifetime of struct literal temporary used for pass-by-value. A proposal aimed at binding rvalues to references must address lifetime of temporaries as a central concern. 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role. auto ref is a template-world entity. If by improved you mean completely reworked than sure, I can add this rationale. Will do today. I think we should focus on http://d.puremagic.com/issues/show_bug.cgi?id=9238 and on making ref safe. 4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to ref and to make auto ref work as a reference that can bind to rvalues as well as lvalues. Can't agree. scope is defined (but not implemented, a pity). Creating temporaries already exists for some cases. No really new language feature is added. No special syntax created. scope ref is still scope and ref with all semantics this imposes, rvalue references are just a side-effect. Contrary to this, auto ref IS a new feature created specifically for syntax hack. That is a very problem you are speaking about - introducing new concepts instead of making use of ones that exist for ages. You are of course to disagree, but that would make you wrong. Andrei
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 understand the usability disaster of disallowing rvalue references is that I have to define a non-ref overload forwarding to my function(ref arg). That ref can't be for functionality, because I'm expecting references to rvalues/temporaries. = ref is merely for performance, and the parameter can be const. 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 that would be it. Aliasing would kill that. We considered it. Andrei
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 language is fixed? Do you fix it and break code, or do you leave it broken? I am more for following the C/C++ solution: periodical revise the language, but not every two months. Several years and once that the compiler infrastructure is already in place and tested, publish (officially) the new version. During the meantime, users could live with workarounds and forbidden to do that!. Look at C and MISRA-C. It won't help to declare a stable version of D, while keep adding new things. What would really help is to stop adding new things, remove those that we are in doubt if they are good or no (properties?) or, at least, leave them as they are, then move towards improving the tools. A cleaner language with better tools will allow D to take off, while still leaving room for possible improvements in future revisions. C++ did not start as a perfect language, nor it has become, still there are tools for it, people are using it, companies are hiring C++ developers. Being predictable does matter sometimes. Tools matter too. 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
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 primarily and rvalue ref solution only secondarily. My initial reason was to solve the rvalue ref issue. So it is completly inverse for me. :-) And I initially ignored all the threads you have started until noticed proposal that looked fundamental enough in its nature. :) Features created to support one specific use case usually are not worth it. DIP36 as far as I see it is much more about scope than about rvalues. If it were about scope it would be very careful with lifetime of temporaries. Andrei
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 preference should be putting the existing features in good order. 2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects. 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role. 4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to ref and to make auto ref work as a reference that can bind to rvalues as well as lvalues. Andrei
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 sane lifetime rules that would result in violating this.
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: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 exists while called function is executed. I can't imagine any sane lifetime rules that would result in violating this. This isn't enough for a DIP. You have to explicitly define the lifetime, as it is required to know what is safe and what isn't, to get deterministic destruction, or whatever.
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 problem (FF, Safari and Chrome). It only happens when I do a hard reload, that is, don't use anything from the local cache. The following things happens when I do a hard reload: * The HTML classes page_left, divider_v and page_right has the CSS style property height set to 637px * I get the following JavaScript error: NetworkError: 503 Service Unavailable - http://search.twitter.com/search.json?q=%23dconf%20OR%20from%3AD_programming%20OR%20%40D_programminginclude_rts=truecallback=TWTR.Widget.receiveCallback_1rpp=20clientsource=TWITTERINC_WIDGETresult_type=mixed1366729612406= (That is not the full URL) * JavaScript error: TypeError: that.decay is not a function. Most likely due to the error above If I then do a normal reload I don't get any JavaScript errors and the HTML classes above have their height set to 703px. This is easy to see in any web browser using its built in developer tools. Just right click anywhere on the page and choose Inspect element. Then choose the Console tab. -- /Jacob Carlborg
Re: rvalue references
On 24 April 2013 00:30, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote: 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 preference should be putting the existing features in good order. I see it in exactly the opposite way. This does put an existing feature in good order, ie, scope, which is defined but barely implemented, and might as well have been invented for this purpose as far as I can tell from what little information is available about it. 2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects. Is that the only detail missing? An r-value passed this way produces a temp, which is a stack variable. It's life is identical to any other stack variable, ie, it lives for the life of the function where it appears. 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role. auto-ref is a template concept (necessary because ref is not part of the type like in c++). It doesn't make sense to me at all being forced into this concept. I see people saying it over and over, but I just can't see it. How does 'auto' apply conceptually? It's a template concept by definition. It feels like auto-ref is deliberately contriving a concept to fit a problem, not DIP36. 4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. Again, I can't see how this is a new feature at all. It's precisely what you say; making an existing feature (scope) that already exists and is defined actually work, and elegantly solve the problem. auto-ref on the other hand IS a new feature (in this context), and it also makes no sense if you ask me. It's a template concept which is not applicable here. In particular we are much more inclined to impart real, demonstrable safety to ref ref is unsafe by definition. I don't believe this is possible without some further justification. DIP36 however creates a situation where it's known that passing a temp is actually safe. and to make auto ref work as a reference that can bind to rvalues as well as lvalues. What does it mean to make a reference bind to r-values aswell as l-values? Lots of people keep saying this too, but it doesn't really make sense to me either. No reference can bind to r-values, r-values can not be addressed. It's really a temp copy of said r-value that we're dealing with, which is an l-value, ie, a local with a lifetime that's unsuitable for passing by non-scope-ref. scope-ref would promise that it won't escape the callee, and thus is safe to pass a temp. ref is fundamentally broken in D right now. DIP36 creates a situation where it could be fixed. I would personally take DIP36 one step further, and ban all local's from being passed to non-scope ref. Yes, a breaking change, but you could argue that any code that passes a stack variable to any ref arg is already broken. But this can be addressed in a future DIP. ...perhaps I'm missing something fundamental in DIP36, or about 'auto ref'? I can't understand why there seem to be 2 polarised parties on this issue, which appear to see the problem completely differently, and can't visualise the counter perspective at all.
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 mailnew4s...@gmail.com 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 has a fixed size in pixels. I don't see that problem in firefox, or opera -Steve The problem is subtle, a javascript is bugguy and set a wrong height. I already reported that one a while ago xD
Re: rvalue references
On 24 April 2013 01:01, deadalnix deadal...@gmail.com 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 explain. In its current form DIP36 only cares that passed temporary exists while called function is executed. I can't imagine any sane lifetime rules that would result in violating this. This isn't enough for a DIP. You have to explicitly define the lifetime, as it is required to know what is safe and what isn't, to get deterministic destruction, or whatever. 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
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 finish it. Andrei 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role. I and probably many other have thought that auto ref cannot work for non-templates because that would mean, that auto ref would work differently for templates and non-templates. That was the main reason to search for an alternative. But have you any ideas how auto ref should do this for non-templates? E.g. with creating temporary lvalues, doubled the function etc.? That would make it easier to support you.
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 div class=page_right equal element has a hard-coded height (643px). Removing that inline styling it works for me.
Re: DIP 36: Rvalue References
On 24 April 2013 00:24, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote: 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 and auto ref without any palpable benefit and defines yet another way to achieve the same thing as auto ref. On this ground alone the proposal has a large problem. How does it overlap ref? It simply justifies the argument with an extra constraint and isn't tied to 'ref' at all, it's just useful in conjunction. I can't agree that it overlaps auto-ref at all. They're fundamentally different concepts. auto-ref is a template concept; it selects the ref-ness based on the received arg. 'auto ref', ie, 'automatic ref-ness'. It makes no sense on a non-template situation. I'm still completely amazed that the very reason this DIP makes perfect sense to me(/us) is the same reason you have a problem with it. 2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects. It can't because lifetime of temporaries is not defined in D at all and suck stuff needs to be consistent. It is not really different from a lifetime of struct literal temporary used for pass-by-value. A proposal aimed at binding rvalues to references must address lifetime of temporaries as a central concern. It's not an r-value, it's a standard stack-allocated temporary. It's lifetime is identical to any other local. The reason it's not detailed in the proposal is because it adds no such new feature, and makes no changes. The lifetime of a local is well understood. 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role. auto ref is a template-world entity. If by improved you mean completely reworked than sure, I can add this rationale. Will do today. I think we should focus on http://d.puremagic.com/issues/** show_bug.cgi?id=9238 http://d.puremagic.com/issues/show_bug.cgi?id=9238and on making ref safe. I don't believe it's possible to make ref safe. Can you suggest any vision for this? It's unsafe by definition... you are passing a pointer of unknown origin to a function that could do anything with that pointer. Hence 'scope ref', which appropriately restricts what the callee is able to do with it. 4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to ref and to make auto ref work as a reference that can bind to rvalues as well as lvalues. Can't agree. scope is defined (but not implemented, a pity). Creating temporaries already exists for some cases. No really new language feature is added. No special syntax created. scope ref is still scope and ref with all semantics this imposes, rvalue references are just a side-effect. Contrary to this, auto ref IS a new feature created specifically for syntax hack. That is a very problem you are speaking about - introducing new concepts instead of making use of ones that exist for ages. You are of course to disagree, but that would make you wrong. Explain why? Proclaiming he is simply wrong when he presents sound reason isn't helpful.
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 as well (with the exception that you CAN return a ref, but it turns out it would also be safe to return a scope ref in those circumstances). DIP25 imposes a number of code-breaking restrictions even in @system code, if DIP36 was in place, one could consider imposing the DIP25 restrictions only in SafeD. Yes, the addressof part of DIP25 would cause problems, but the part to do with safety of ref will not. IMO we shouldn't start trying to add rvalue references until we've solved the safety of normal references. We should therefore split DIP25 into two parts: - The part that guarantees safety of ref can be implemented right away (just make taking the address of a reference unsafe instead of adding addressof). There is simply no avoiding implementing something like this if you want safe references. - The part to do with fixing syntactic ambiguities of , adding addressof and making ref more restrictive can be a separate DIP. This is the one that would potentially break code. If we do this first, the issue of rvalue references becomes a non-issue. Even without explicitly defining what the lifetime of an rvalue reference is it becomes safe to pass them as ref: - In DIP25 it is the caller who enforces the safety of ref, the callee just has to follow the same simple rules. - The caller will always know the lifetime of anything it passes in, so it is simple to ensure that it doesn't last beyond that. Furthermore if one day the compiler would be sufficiently smart to infer scope automatically, there still would be an important difference between 'ref' and 'scope ref'. That's not what I'm saying, even with no inference on behalf of the compiler there is still no difference between scope ref and ref.
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 function is executed. I can't imagine any sane lifetime rules that would result in violating this. One matter to look into is returning scope ref from functions (which is useful). Andrei
Re: rvalue references
On 4/23/13 11:27 AM, Manu wrote: On 24 April 2013 00:30, Andrei Alexandrescu seewebsiteforem...@erdani.org 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 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 preference should be putting the existing features in good order. I see it in exactly the opposite way. This does put an existing feature in good order, ie, scope, which is defined but barely implemented, and might as well have been invented for this purpose as far as I can tell from what little information is available about it. 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. 2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects. Is that the only detail missing? Many details are missing. This is not a simple problem. An r-value passed this way produces a temp, which is a stack variable. It's life is identical to any other stack variable, ie, it lives for the life of the function where it appears. That's a possibility, but it's a departure from current semantics and is not mentioned in the DIP. 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role. auto-ref is a template concept (necessary because ref is not part of the type like in c++). It doesn't make sense to me at all being forced into this concept. I see people saying it over and over, but I just can't see it. How does 'auto' apply conceptually? It's a template concept by definition. It feels like auto-ref is deliberately contriving a concept to fit a problem, not DIP36. Well feeling a certain way is fine but it doesn't help rigorous definitions. The scope ref feature is adding no value over what we have and need to get in good order. People would come and ask, how can a function accept both rvalues and lvalues by reference? and then experts will answer with, well is that a template or a non-template? because the means are entirely different. Why are they different? And the experts will answer just like you: By definition - thus closing the circle. 4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. Again, I can't see how this is a new feature at all. It's precisely what you say; making an existing feature (scope) that already exists and is defined actually work, and elegantly solve the problem. This is a new feature. There is no existing feature scope. auto-ref on the other hand IS a new feature (in this context), and it also makes no sense if you ask me. It's a template concept which is not applicable here. It is a feature that has been implemented and works, just not in all cases. In particular we are much more inclined to impart real, demonstrable safety to ref ref is unsafe by definition. We want to aim at making ref safe, thus making it useful as restricted pass-down pointers. For full possibilities, one should use pointers. I don't believe this is possible without some further justification. The justification is that unsafe uses of ref are few and uninteresting (they can be replaced with pointers). It would be very powerful to be able to guarantee that safe code can use ref. DIP36 however creates a situation where it's known that passing a temp is actually safe. and to make auto ref work as a reference that can bind to rvalues as well as lvalues. What does it mean to make a reference bind to r-values aswell as l-values? Lots of people keep saying this too, but it doesn't really make sense to me either. I don't understand the question as the answer is in it. No reference can bind to r-values, r-values can not be addressed. But auto ref and scope ref do bind to r-values. It's really a temp copy of said r-value that we're dealing with, which is an l-value, ie, a local with a lifetime that's unsuitable for passing by non-scope-ref. scope-ref would promise that it won't escape the callee, and thus is safe to pass a temp. Our aim is to have ref make that promise. ref is fundamentally broken in D right now. DIP36 creates a situation where it could be fixed. A new feature is not a fix. I would personally take DIP36 one step further, and ban all local's from being passed to non-scope ref. Yes, a breaking change, but you could argue that any code that passes a stack variable to any ref arg is already broken. But this can be addressed in a future DIP.
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=9238 but I never had the time to finish it. Andrei 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role. I and probably many other have thought that auto ref cannot work for non-templates because that would mean, that auto ref would work differently for templates and non-templates. That was the main reason to search for an alternative. I recall Walter has been the first to put this forward, but has been convinced otherwise. We can make auto ref work for non-templates, even if the implementation is different. The main issues are returning ref from functions and lifetime of temporaries, as discussed in http://d.puremagic.com/issues/show_bug.cgi?id=9238. But have you any ideas how auto ref should do this for non-templates? E.g. with creating temporary lvalues, doubled the function etc.? That would make it easier to support you. There would be one implementation of the function. Binding rules, typechecking the function, and lifetime of temporaries may be changed. Andrei
Re: DIP 36: Rvalue References
On 4/23/13 12:04 PM, Manu wrote: On 24 April 2013 00:24, Andrei Alexandrescu seewebsiteforem...@erdani.org 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 can be used for same purpose. It's a new feature, no two ways about it. It overlaps ref and auto ref without any palpable benefit and defines yet another way to achieve the same thing as auto ref. On this ground alone the proposal has a large problem. How does it overlap ref? It simply justifies the argument with an extra constraint and isn't tied to 'ref' at all, it's just useful in conjunction. The best setup would be: 1. To take lvalues by reference, write ref. 2. To take lvalues and rvalues by reference, write auto ref. Everything else is superfluous and puts the burden of justification on the proposer. With DIP36, the setup would be: 1. To take lvalues by reference, write ref. 2. To take lvalues and rvalues by reference: 2.1. Is it a template? Then write auto ref. 2.2. Is it a non-template? Then write scope ref. I can't agree that it overlaps auto-ref at all. They're fundamentally different concepts. auto-ref is a template concept; it selects the ref-ness based on the received arg. 'auto ref', ie, 'automatic ref-ness'. It makes no sense on a non-template situation. I'm still completely amazed that the very reason this DIP makes perfect sense to me(/us) is the same reason you have a problem with it. I don't know how to respond to this. To me is it painfully obvious DIP 36 is poor language design and fails to solve a variety of issues, such as clarifying lifetime of temporaries, safety, and returning ref from functions. 2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects. It can't because lifetime of temporaries is not defined in D at all and suck stuff needs to be consistent. It is not really different from a lifetime of struct literal temporary used for pass-by-value. A proposal aimed at binding rvalues to references must address lifetime of temporaries as a central concern. It's not an r-value, it's a standard stack-allocated temporary. It's lifetime is identical to any other local. The reason it's not detailed in the proposal is because it adds no such new feature, and makes no changes. The lifetime of a local is well understood. Currently rvalues are destroyed immediately after the call they are passed into. DIP 36 would need to change that, but fails to specify it. 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role. auto ref is a template-world entity. If by improved you mean completely reworked than sure, I can add this rationale. Will do today. I think we should focus on http://d.puremagic.com/issues/__show_bug.cgi?id=9238 http://d.puremagic.com/issues/show_bug.cgi?id=9238 and on making ref safe. I don't believe it's possible to make ref safe. Can you suggest any vision for this? http://d.puremagic.com/issues/show_bug.cgi?id=9238 It's unsafe by definition... you are passing a pointer of unknown origin to a function that could do anything with that pointer. Hence 'scope ref', which appropriately restricts what the callee is able to do with it. Our intent is to make ref always scoped and reserve non-scoped uses to pointers. We consider this good language design: we have unrestricted pointers for code that doesn't care much about safety, and we have ref which is almost as powerful but sacrifices a teeny bit of that power for the sake of guaranteed safety. Safety is guaranteed by making sure ref is always scoped (references can be passed down but never escape their bound value). 4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to ref and to make auto ref work as a reference that can bind to rvalues as well as lvalues. Can't agree. scope is defined (but not implemented, a pity). Creating temporaries already exists for some cases. No really new language feature is added. No special syntax created. scope ref is still scope and ref with all semantics this imposes, rvalue references are just a side-effect. Contrary to this, auto ref IS a new feature created
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 Tue, 23 Apr 2013 13:33:31 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org 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 compilation model? We consider this good language design: we have unrestricted pointers for code that doesn't care much about safety, and we have ref which is almost as powerful but sacrifices a teeny bit of that power for the sake of guaranteed safety. Safety is guaranteed by making sure ref is always scoped (references can be passed down but never escape their bound value). Not being able to return ref is a large loss of power. Not arguing in favor of DIP36, but it seems there is a misunderstanding as to what it does. -Steve
Re: rvalue references
On 24 April 2013 03:15, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote: On 4/23/13 11:27 AM, Manu wrote: On 24 April 2013 00:30, Andrei Alexandrescu seewebsiteforem...@erdani.org mailto:SeeWebsiteForEmail@**erdani.orgseewebsiteforem...@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 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 preference should be putting the existing features in good order. I see it in exactly the opposite way. This does put an existing feature in good order, ie, scope, which is defined but barely implemented, and might as well have been invented for this purpose as far as I can tell from what little information is available about it. 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' simply promises that a variable may not escape its scope, no? I think it's important to recognise it as 'scope' + 'ref', the 2 don't have any special meaning when put together, just the logical compound, which allows for a safe situation for temporaries that wasn't previously available. 2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects. Is that the only detail missing? Many details are missing. This is not a simple problem. So what are some others? An r-value passed this way produces a temp, which is a stack variable. It's life is identical to any other stack variable, ie, it lives for the life of the function where it appears. That's a possibility, but it's a departure from current semantics and is not mentioned in the DIP. I think it's presumed in the DIP, and it's certainly how Kenji implemented it. What 'current' semantic is it a departure from? The one where passing a literal produces a compile error? Certainly, that's the point. auto-ref on the other hand IS a new feature (in this context), and it also makes no sense if you ask me. It's a template concept which is not applicable here. It is a feature that has been implemented and works, just not in all cases. This isn't a 'case'. It's a separate issue. Safely passing a temp to a ref function arg, and whether a template argument is automatically determined to be ref or not are barely related problems. I still can't see how auto-ref has any business in this context. In particular we are much more inclined to impart real, demonstrable safety to ref ref is unsafe by definition. We want to aim at making ref safe, thus making it useful as restricted pass-down pointers. For full possibilities, one should use pointers. Okay, I'm good with that too, but how is that intended to work? If the intent is to make ref escaping disallowed by default, that is a major breaking change... Can we start talking about virtual-by-default again while we're at it? I don't believe this is possible without some further justification. The justification is that unsafe uses of ref are few and uninteresting (they can be replaced with pointers). It would be very powerful to be able to guarantee that safe code can use ref. Again, this sounds like a major breaking change. Why is scope-ref inferior? It's more informative, and offers more flexibility (ie, the option of ref with or without scope) DIP36 however creates a situation where it's known that passing a temp is actually safe. and to make auto ref work as a reference that can bind to rvalues as well as lvalues. What does it mean to make a reference bind to r-values aswell as l-values? Lots of people keep saying this too, but it doesn't really make sense to me either. I don't understand the question as the answer is in it. No reference can bind to r-values, r-values can not be addressed. But auto ref and scope ref do bind to r-values. It's really a temp copy of said r-value that we're dealing with, which is an l-value, ie, a local with a lifetime that's unsuitable for passing by non-scope-ref. scope-ref would promise that it won't escape the callee, and thus is safe to pass a temp. Our aim is to have ref make that promise. ref is fundamentally broken in D right now. DIP36 creates a situation where it could be fixed. A new feature is not a fix. If scope is a new feature, then the keyword shouldn't compile and pretend that it does stuff. It's an incomplete/unimplemented feature, not a new one. People are aware of it, they can write code that presumes it's present and working. It compiles successfully. I would personally take DIP36 one step further, and ban all local's from being passed to non-scope ref. Yes, a breaking change, but you could
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. I'd feel uncomfortable wielding this much power. I don't think this DIP was ready for a formal review (hence there should be no rejecting it yet), but there has been good discussion and experimental implementation as well. I suggest we keep it in draft format. If our attempts at working on ref/auto ref fail, we should revisit this. Andrei
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 seewebsiteforem...@erdani.org 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 thing difficult btw.) Andrei
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 Tue, 23 Apr 2013 14:01:14 -0400, Diggory digg...@googlemail.com 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.
Those rules disallow the following valid code:
struct S
{
int x;
ref S opOpAssign(string op : +)(ref S other) { x += other.x; return
this;}
}
ref S add5(ref S s)
{
auto o = S(5);
return s += o;
}
void main()
{
auto s = S(5);
S s2 = add5(s);
}
Because opOpAssign takes two refs to S, and in add5, we bind one parameter
to a local, we cannot return the result, even though it's perfectly safe
and valid.
The point is simply that there exist valid and safe cases which will be
disallowed by these rules. While maybe it's OK in your mind to restrict
the above code from validity, it's currently valid and compiling code.
You will be breaking existing code for pretty much no reason.
-Steve
Re: DIP 36: Rvalue References
On 24 April 2013 03:33, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote: On 4/23/13 12:04 PM, Manu wrote: On 24 April 2013 00:24, Andrei Alexandrescu seewebsiteforem...@erdani.org mailto:SeeWebsiteForEmail@**erdani.orgseewebsiteforem...@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 can be used for same purpose. It's a new feature, no two ways about it. It overlaps ref and auto ref without any palpable benefit and defines yet another way to achieve the same thing as auto ref. On this ground alone the proposal has a large problem. How does it overlap ref? It simply justifies the argument with an extra constraint and isn't tied to 'ref' at all, it's just useful in conjunction. 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 at all. It still doesn't make sense. There's nothing 'automatic' about it, I've specified ref, it is ref, there's no other choice. And it relies on a major breaking change to ref, which restricts the functionality of ref by default. Everything else is superfluous and puts the burden of justification on the proposer. With DIP36, the setup would be: 1. To take lvalues by reference, write ref. 2. To take lvalues and rvalues by reference: 2.1. Is it a template? Then write auto ref. 2.2. Is it a non-template? Then write scope ref. Stop talking about r-values, rather, consider safety of passing temporaries. This problem has nothing to do with r-values, this is equally unsafe: void f(ref int x); int x; f(x); It's precisely the same problem, and should be fixed with the same solution. I would rewrite your list as such: 1. 'un-safely' pass a value (may not be a local), write 'ref' 2. safely pass a value (may be a local), write 'scope ref' 3. if you are concerned with templates do you: 3.a. want unsafe auto-ref, type 'auto ref' (only non-locals would generate 'ref') 3.b. want safe auto-ref, type 'scope auto ref' The automatic selection of ref for templates is fairly unrelated to this issue. I can't agree that it overlaps auto-ref at all. They're fundamentally different concepts. auto-ref is a template concept; it selects the ref-ness based on the received arg. 'auto ref', ie, 'automatic ref-ness'. It makes no sense on a non-template situation. I'm still completely amazed that the very reason this DIP makes perfect sense to me(/us) is the same reason you have a problem with it. I don't know how to respond to this. To me is it painfully obvious DIP 36 is poor language design and fails to solve a variety of issues, such as clarifying lifetime of temporaries, safety, and returning ref from functions. Lifetime of temporaries is the most basic of principles. A local lives the life of the function in which it is defined. Safety is the whole point, and intrinsic to the proposal; safety by explicit specification, thus the programmer retains the option. If a function receives 'scope ref', and wants to return it, I think it should also return 'scope ref' (I guess this wasn't defined in the DIP), otherwise it would be considered an escape. 2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects. It can't because lifetime of temporaries is not defined in D at all and suck stuff needs to be consistent. It is not really different from a lifetime of struct literal temporary used for pass-by-value. A proposal aimed at binding rvalues to references must address lifetime of temporaries as a central concern. It's not an r-value, it's a standard stack-allocated temporary. It's lifetime is identical to any other local. The reason it's not detailed in the proposal is because it adds no such new feature, and makes no changes. The lifetime of a local is well understood. Currently rvalues are destroyed immediately after the call they are passed into. DIP 36 would need to change that, but fails to specify it. Again, I think it was presumed (I can't conceive any other approach), and certainly Kenji read it that way, because his code appears to do just that. 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role. auto ref is a template-world entity. If by improved you mean completely reworked than sure, I can add this rationale. Will do today. I think we should focus on http://d.puremagic.com/issues/**__show_bug.cgi?id=9238http://d.puremagic.com/issues/__show_bug.cgi?id=9238
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 trying to achieve with mousepressevent? I want to: *have undecorated window with Notebook - ok, no problem *reorderable tabs - ok, no problem *begin move window when press on Notebook - I need that You will need to add the event handler to the containers you are addin to the page. And in the case of the small example you posted, where you add only a single Label to the page it needs to be wrapped in an EventBox. Is far as i know that shouldn't be necessary when you are adding an other container to the page. http://dpaste.dzfl.pl/adc350a4 Can I check if the mouse is above a tab in Notebook with mouse move / motion event ? If I could do it, then I can put a condition that checks it and assigns a value to a Boolean variable. Thus, in the event of pressing the left mouse button I check this variable and dependent on this I can move a window or not. -- Mike Wey
Re: rvalue references
On 4/23/13 2:00 PM, Manu wrote:
On 24 April 2013 03:15, Andrei Alexandrescu
seewebsiteforem...@erdani.org 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' simply promises that a variable may not escape its
scope, no?
I think it's important to recognise it as 'scope' + 'ref', the 2 don't
have any special meaning when put together, just the logical compound,
which allows for a safe situation for temporaries that wasn't previously
available.
I understand. This could surely be used as an appeal to intuition for
the added feature, but it's in no way a justification that it's not a
new feature.
Many details are missing. This is not a simple problem.
So what are some others?
Returning a reference is an important topic.
An r-value passed this way produces a
temp, which is a stack variable. It's life is identical to any other
stack variable, ie, it lives for the life of the function where
it appears.
That's a possibility, but it's a departure from current semantics
and is not mentioned in the DIP.
I think it's presumed in the DIP, and it's certainly how Kenji
implemented it.
What 'current' semantic is it a departure from? The one where passing a
literal produces a compile error? Certainly, that's the point.
Currently, rvalues exist until they have been consumed by a call. By DIP
36, some rvalues exist through the end of the function.
auto-ref on the other hand IS a new feature (in this context),
and it
also makes no sense if you ask me. It's a template concept which
is not
applicable here.
It is a feature that has been implemented and works, just not in all
cases.
This isn't a 'case'. It's a separate issue.
Safely passing a temp to a ref function arg, and whether a template
argument is automatically determined to be ref or not are barely related
problems.
I still can't see how auto-ref has any business in this context.
They are related inasmuch they solve the same problem (define a function
that accepts both lvalues and rvalues). They are distinct because
currently in a template you could at least in theory figure out whether
the function has been called with an lvalue on rvalue. The code below
does not currently work but could be made to work:
void fun(T)(auto ref T t)
{
static if (is(t == ref)) {}
}
If we decide this feature is unnecessary (as I suspect is the case), we
should change the implementation of auto ref to only use one body for
both ref and non-ref versions.
In particular we are much more inclined to impart real,
demonstrable
safety to ref
ref is unsafe by definition.
We want to aim at making ref safe, thus making it useful as
restricted pass-down pointers. For full possibilities, one should
use pointers.
Okay, I'm good with that too, but how is that intended to work?
If the intent is to make ref escaping disallowed by default, that is a
major breaking change...
Walter and I are inclined to take the hit because we believe the upside
is worth it.
Can we start talking about virtual-by-default again while we're at it?
There are no plans to change that.
I don't believe this is possible without
some further justification.
The justification is that unsafe uses of ref are few and
uninteresting (they can be replaced with pointers). It would be very
powerful to be able to guarantee that safe code can use ref.
Again, this sounds like a major breaking change.
Why is scope-ref inferior? It's more informative, and offers more
flexibility (ie, the option of ref with or without scope)
Whether scope ref is inferior to the ref/auto ref combo is a judgment
call. On the face of it, any new feature has to prove its utility so it
starts from a somewhat disadvantaged position.
DIP36 however creates a situation where it's known that passing
a temp
is actually safe.
and to make auto ref work as a reference that can bind to
rvalues
as well as lvalues.
What does it mean to make a reference bind to r-values aswell as
l-values? Lots of people keep saying this too, but it doesn't really
make sense to me either.
I don't understand the question as the answer is in it.
No reference can bind to r-values, r-values can not be addressed.
This is a matter of language definition. Rvalues can be bound to
references today, and the bound references can be addressed.
struct S { void fun() { writeln(this); } }
unittest { S().fun(); }
But auto ref and scope ref do bind to r-values.
It's
really a temp copy of said r-value that we're dealing with,
which is an
l-value, ie, a local with a lifetime
Re: DIP 36: Rvalue References
On 24 April 2013 04:01, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote: On 4/23/13 1:57 PM, Steven Schveighoffer wrote: On Tue, 23 Apr 2013 13:33:31 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org** 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 thing difficult btw.) I think the key that's not in this DIP is that it should also return 'scope ref' to maintain the safety. This brings the proposal in-line with your plans, except the safety is explicit, and the option is available to the programmer. Making 'safe' ref the default is a major breaking change.
Re: DIP 36: Rvalue References
On 4/23/13 2:29 PM, Manu wrote: On 24 April 2013 03:33, Andrei Alexandrescu seewebsiteforem...@erdani.org 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 at all. It still doesn't make sense. There's nothing 'automatic' about it, There is - it means ref is inferred. I've specified ref, it is ref, there's no other choice. Well auto ref means I don't care whether this is ref or not. And it relies on a major breaking change to ref, which restricts the functionality of ref by default. This is a confusion. There's no reliance on any change to ref. The breaking changes are related to adding safety. If safety weren't a concern, a lot of things would be simple. Stop talking about r-values, rather, consider safety of passing temporaries. This problem has nothing to do with r-values, this is equally unsafe: void f(ref int x); int x; f(x); It's precisely the same problem, and should be fixed with the same solution. We should make the code above safe as is. I would rewrite your list as such: 1. 'un-safely' pass a value (may not be a local), write 'ref' 2. safely pass a value (may be a local), write 'scope ref' 3. if you are concerned with templates do you: 3.a. want unsafe auto-ref, type 'auto ref' (only non-locals would generate 'ref') 3.b. want safe auto-ref, type 'scope auto ref' This a terrible, terrible list. I'd be ashamed to have to explain this with a straight face. I don't know how to respond to this. To me is it painfully obvious DIP 36 is poor language design and fails to solve a variety of issues, such as clarifying lifetime of temporaries, safety, and returning ref from functions. Lifetime of temporaries is the most basic of principles. A local lives the life of the function in which it is defined. Safety is the whole point, and intrinsic to the proposal; safety by explicit specification, thus the programmer retains the option. The missing point here is inflicting more complexity on the user. Andrei
Re: DIP 36: Rvalue References
On 4/23/13 2:32 PM, Manu wrote: On 24 April 2013 04:01, Andrei Alexandrescu seewebsiteforem...@erdani.org 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 seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org__ 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 thing difficult btw.) I think the key that's not in this DIP is that it should also return 'scope ref' to maintain the safety. This brings the proposal in-line with your plans, except the safety is explicit, and the option is available to the programmer. We prefer to simplify. Use ref safely for scoped pass-down of resources, use pointers for unrestricted escapes. What you see as offering an option I see as adding a burden. Making 'safe' ref the default is a major breaking change. How do you assess the size of the breakage? Andrei
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 that you have in mind for D. OK. Don't follow the C++ model. But, then, what is the model that D follows? Is there any such model?
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 the (original) meaning of scope to mark parameters that are not going to be returned. (I still think both ref and scope ref should accept rvalues)
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 the closing } of the scope they appear in. There can be many such scopes in a function. There's also the issue of: a || b || c If b creates a temporary, it's life ends at the end of the expression or statement - it's complicated.
