Re: Stable D version?
On Monday, 29 April 2013 at 11:24:02 UTC, Dicebot wrote: On Monday, 29 April 2013 at 11:15:20 UTC, Paulo Pinto wrote: Quoting myself "Or course this is a very limited subset of what embedded is all about, but I think D could also be usable in such types of boards." Okay, pardon me, may be I have not highlighted my point clear enough: there is no real market for D in that limited subset because it has to compete with Java, C# or any modern language based on their virtual machines. And, similar to desktop usage, lot of selling points for D are lost then, because, well, why bother? Contrary to this, any language who can make it into real embedded domain will be almost uncontested, because this industry is still stuck with 40-year obsolete tools. But that is not something that may happen on its own. Fair enough, I agree with you there.
Re: Stable D version?
On Monday, 29 April 2013 at 11:15:20 UTC, Paulo Pinto wrote: Quoting myself "Or course this is a very limited subset of what embedded is all about, but I think D could also be usable in such types of boards." Okay, pardon me, may be I have not highlighted my point clear enough: there is no real market for D in that limited subset because it has to compete with Java, C# or any modern language based on their virtual machines. And, similar to desktop usage, lot of selling points for D are lost then, because, well, why bother? Contrary to this, any language who can make it into real embedded domain will be almost uncontested, because this industry is still stuck with 40-year obsolete tools. But that is not something that may happen on its own.
Re: Stable D version?
On Monday, 29 April 2013 at 10:38:32 UTC, Dicebot wrote: On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote: This guys don't have any issues selling Oberon compilers for embedded use. ... That is simple, "embedded" is a buzzword often understood as "something like PC but small". Such definition is quite useless because it implies no specific requirements. Like, calling modern ARM smartphone an embedded system? No way. You can even afford to have something as inefficient as kernel in Java on those machines, why not. Much more practical definition of "embedded" is all about specific requirements. Real-time systems, systems with hard memory restrictions (imagine coding in environment where malloc is prohibited because every single byte of physical memory is pre-allocated). Those can vary from microchips to monstrous servers and I don't see anything but C or C++ with lot of custom policies used there. Quoting myself "Or course this is a very limited subset of what embedded is all about, but I think D could also be usable in such types of boards."
Re: Stable D version?
On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote: This guys don't have any issues selling Oberon compilers for embedded use. ... That is simple, "embedded" is a buzzword often understood as "something like PC but small". Such definition is quite useless because it implies no specific requirements. Like, calling modern ARM smartphone an embedded system? No way. You can even afford to have something as inefficient as kernel in Java on those machines, why not. Much more practical definition of "embedded" is all about specific requirements. Real-time systems, systems with hard memory restrictions (imagine coding in environment where malloc is prohibited because every single byte of physical memory is pre-allocated). Those can vary from microchips to monstrous servers and I don't see anything but C or C++ with lot of custom policies used there.
Re: Stable D version?
On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote: On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote: ... D is simply in no shape to compete for kernels for same reasons it is rather painful to use in embedded (fat runtime, language features relying on hidden gc allocations etc.) It is hardly practical to discuss the moment to compete when it is not an option from technical point of view. This guys don't have any issues selling Oberon compilers for embedded use. http://www.oberonday2011.ethz.ch/talks/armembedded.pdf http://www.astrobe.com/default.htm A GC enabled systems programming language. Oracle with their Spots and the new Keil board support (Java) http://www.sunspotworld.com/ http://docs.oracle.com/javame/config/cldc/rel/3.3/keil/gs/html/getstart_rtx/running.htm Or the Netduino guys (C#) http://netduino.com/ Or course this is a very limited subset of what embedded is all about, but I think D could also be usable in such types of boards.
Re: Stable D version?
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote: On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote: Linux uses C for the kernel too, mainly because Walter hates C++ (and C++ programmers). err, Linus
Re: Stable D version?
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote: On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote: True, but only now the major OS vendors are switching from C to C++ as their main systems programming language. Curious, which ones are you referring to? Windows uses C for the kernel, for many reasons, one of which is that C (unlike C++) discourages storing large objects on the stack. Linux uses C for the kernel too, mainly because Walter hates C++ (and C++ programmers). Which vendors have switched to C++ for systems programming? BeOS/Haiku - C++ Symbian - C++ MacOS X - Device Drivers are written in a C++ subset (IOKit) z/OS - Original code was Modula-2/Assembly, with new code being C++ Windows - WinRT is C++, C is considered legacy, Herb Sutter stated at BUILD 2012 that Windows team is making kernel code C++ compatible. I can search for the exact minute in the videos if you wish.
Re: Stable D version?
On Monday, 29 April 2013 at 08:07:05 UTC, eles wrote: I even start thinking that is better to release a new feature after a relative short, preliminary discussion, and be prepared to change it during a time frame, if it is not as practical as desired, instead of prolonging a discussion for centuries in the search of the perfect implementation. That brings us back to the "Stable D" subject, and the separation between stable and unstable. Those preliminary features should be included in the unstable releases, where changes can be made without the fear of breaking things. Then, after some actual usage, they would be merged to the stable branch.
Re: Stable D version?
On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote: On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote: D is simply in no shape to compete for kernels for same reasons it is rather painful to use in embedded (fat runtime, language features relying on hidden gc allocations etc.) It is hardly practical to discuss the moment to compete when it is not an option from technical point of view. Well, then a list of what's still missing should be compiled (in terms of features and language changes, not in terms of bugs). An rush to complete it. Some of the issues were discussed since many months, and no definitive decision has been taken (see the @property). I am rather in favor of taking a decision, good or bad, than to prolonge ambiguity. Also for several minor issues (ie: double[$] static arrays and __MODULE__ identifier and so on). For those, I would like to see a more accelerated pace. I even start thinking that is better to release a new feature after a relative short, preliminary discussion, and be prepared to change it during a time frame, if it is not as practical as desired, instead of prolonging a discussion for centuries in the search of the perfect implementation.
Re: Stable D version?
On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote: ... D is simply in no shape to compete for kernels for same reasons it is rather painful to use in embedded (fat runtime, language features relying on hidden gc allocations etc.) It is hardly practical to discuss the moment to compete when it is not an option from technical point of view.
Re: Stable D version?
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote: Am 28.04.2013 12:03, schrieb Dicebot: On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote: I also think when modules are integrated into the C++ True, but only now the major OS vendors are switching from C to C++ as their main systems programming language. I think that exactly because it is a switch *in the happening*, it is the moment for D to be involve in that switch. Because project managers are considering switching and they look for alternatives. Maybe some of them will tell themselves: "well, if we switch, why do not take that D in consideration? at least, for experimenting and see what it gives". It is useless to be a good alternative if nobody wants to switch. If they go down on the C++ path, then two things will happen: -they will be even more reluctant to do another switch, while their code base matures (and, do not forget, interoperability or portability from C to D is one thing; form C++ to D is a different, huge, beast). -C++ will get more traction and more pressure to improve itself, from vendors and community at large. it will advance faster. In the end, we should not be sorry, as programmers we will win better language, better tools. But I am afraid that D will not win as much.
Re: Stable D version?
On 2013-04-29 01:11, Mehrdad wrote: Curious, which ones are you referring to? Windows uses C for the kernel, for many reasons, one of which is that C (unlike C++) discourages storing large objects on the stack. Linux uses C for the kernel too, mainly because Walter hates C++ (and C++ programmers). Which vendors have switched to C++ for systems programming? The kernel in Mac OS X is written in a subset of C++. -- /Jacob Carlborg
Re: Stable D version?
On Monday, 29 April 2013 at 04:19:06 UTC, Oleg Kuporosov wrote: On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote: On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote: Which vendors have switched to C++ for systems programming? Paolo probably had MS in mind which didn't release WinRT for C. Ah ok... but that's not really "systems programming", it's pretty high-level.
Re: Stable D version?
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote: On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote: Which vendors have switched to C++ for systems programming? Paolo probably had MS in mind which didn't release WinRT for C.
Re: Stable D version?
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote: True, but only now the major OS vendors are switching from C to C++ as their main systems programming language. Curious, which ones are you referring to? Windows uses C for the kernel, for many reasons, one of which is that C (unlike C++) discourages storing large objects on the stack. Linux uses C for the kernel too, mainly because Walter hates C++ (and C++ programmers). Which vendors have switched to C++ for systems programming?
Re: Stable D version?
Am 28.04.2013 12:03, schrieb Dicebot: On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote: I also think when modules are integrated into the C++ standard, for most developers, there won't be any case left for D. Even though D technically is superior in almost every way, conservatism is strong enough. C++ will never be sufficiently changed to leave no chance for other native languages. It is doomed because of mandatory backwards compatibility with huge legacy package. Main issues of C++ are not lack of advanced features but inconvenient design of basic features. Well, D is trying to have its own share of those issues too :P True, but only now the major OS vendors are switching from C to C++ as their main systems programming language. How long will take until they replace it with something else? -- Paulo
Re: Stable D version?
On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote: I also think when modules are integrated into the C++ standard, for most developers, there won't be any case left for D. Even though D technically is superior in almost every way, conservatism is strong enough. C++ will never be sufficiently changed to leave no chance for other native languages. It is doomed because of mandatory backwards compatibility with huge legacy package. Main issues of C++ are not lack of advanced features but inconvenient design of basic features. Well, D is trying to have its own share of those issues too :P
Re: Stable D version?
On Tuesday, 23 April 2013 at 20:21:55 UTC, eles wrote: On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu I was mainly referring to the fact that C++ succeeded in spite of having initially an incomplete specification. Nowadays the expectations are much higher. Andrei As long as you keep changing the language, no specification will ever be complete. C++ will long advance. D must be out and living before C++14. Then, it will be too late. My view. I also think when modules are integrated into the C++ standard, for most developers, there won't be any case left for D. Even though D technically is superior in almost every way, conservatism is strong enough.
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: Sorry, I was rude here and I apologize. Finally, D is (at least) a wonderful place to discuss and test new ideas and, while I would like it to take off faster, a too early rush won't make any good.
Re: Stable D version?
On Tuesday, April 23, 2013 07:02:39 Mehrdad wrote: > Well, I think the float behavior is correct and the string > example is broken, but that wasn't my point anyway. > > The point was that it's still broken. According to TDPL (section 7.1.5.2, p. 258 - 259), == on structs should be equivalent to using == on each of the struct's members: http://d.puremagic.com/issues/show_bug.cgi?id=3789 Doing anything else would be inconsistent, and the way that it is has definitely been causing problems and forces people to overload opEquals way more often than strictly speaking should be necessary. - Jonathan M Davis
Re: Stable D version?
On Tuesday, 23 April 2013 at 20:21:55 UTC, eles wrote: On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu I was mainly referring to the fact that C++ succeeded in spite of having initially an incomplete specification. Nowadays the expectations are much higher. Andrei As long as you keep changing the language, no specification will ever be complete. C++ will long advance. D must be out and living before C++14. Then, it will be too late. My view. I don't see on what C++14 will really change the current state of C++? Changes aren't import for every day developments, C++14, won't import fast build, safe language specifications (removal of multiple inheritance, no removal of error prone syntaxes, specified initialization values, mandatory override keyword, ...),... D don't have to compete C++, let D maturate. If you are hurry to see D in the industry maybe you can contribute on tools, libraries,...
Re: Stable D version?
Am 23.04.2013 22:21, schrieb eles: On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu I was mainly referring to the fact that C++ succeeded in spite of having initially an incomplete specification. Nowadays the expectations are much higher. Andrei As long as you keep changing the language, no specification will ever be complete. C++ will long advance. D must be out and living before C++14. Then, it will be too late. My view. C++ was created around 1985, that is 28 years as of today. I remember going through the ARM (Annotated Reference Manual) around 1995 and not finding a C++ compiler that was able to compile all examples. Following "The C Users Journal", shortly thereafter renamed "The C/C++ Users Journal" and "C++ Report" and seeing the language change each month, with each C++ compiler offering a different view what the language meant. C++ will be with us for many years to come, but you should not forget that it has a few years in the industry already, and as I mentioned in a separate post, systems programming languages require support from OS vendors. As a supporter for stronger typed languages I look forward not only D, but Rust and Go as well, even with its issues, to gain wider support, but it takes time. -- Paulo
Re: Stable D version?
On 04/23/2013 10:21 PM, eles wrote: On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu I was mainly referring to the fact that C++ succeeded in spite of having initially an incomplete specification. Nowadays the expectations are much higher. Andrei As long as you keep changing the language, no specification will ever be complete. It is the other way round. As long as there is no specification, there are no language changes, as everything can be cast as a bug fix towards implementing some imaginary specification that is different for each dev. C++ will long advance. D must be out and living before C++14. Then, it will be too late. I think there is no reason to assume that C++ can be fixed. My view. Obviously.
Re: Stable D version?
On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu I was mainly referring to the fact that C++ succeeded in spite of having initially an incomplete specification. Nowadays the expectations are much higher. Andrei As long as you keep changing the language, no specification will ever be complete. C++ will long advance. D must be out and living before C++14. Then, it will be too late. My view.
Re: Stable D version?
On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu wrote: I think we shouldn't follow the C++ model. Whatever made C++ successful is not what'll make D successful. The context and expectations are very different now. Andrei That's a pretty vague 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? I was mainly referring to the fact that C++ succeeded in spite of having initially an incomplete specification. Nowadays the expectations are much higher. 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: 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: 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?... Radons&Minayev 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: 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: Stable D version?
On Tuesday, 23 April 2013 at 09:23:50 UTC, Iain Buclaw wrote: On 23 April 2013 09:56, 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? 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: Stable D version?
On 23 April 2013 09:56, 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? > 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 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: 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: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: 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: 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: 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: 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: 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: 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: 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 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?... Radons&Minayev 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: 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 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: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: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 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: 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: 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: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: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: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: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: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 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. I guess C and C++ aren't even considered languages anymore.
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: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: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 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: 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 05:28:54 UTC, Mehrdad wrote: If when you see a == b you think, Hey, that's equivalent to (a.d is b.d) I suppose that when you see (a is b) you think, Hey, that's equivalent to a.d == b.d ? Incorrect. When I see a == b, I don't think anything. Thanks to encapsulation, typeof(a) and typeof(b) gets to decide what "==" means. If they happen to be structs, then if the author defined opEquals, then that's what it means. Otherwise, it's just a simple bitwise comparison (or should be). If it doesn't make sense, it's broken. Implementing == as 'is' by default doesn't make sense when there is already an 'is' operator that could do the same, hence it's broken. It doesn't make sense to _you_. It's a purely subjective matter. And considering I've explained the way to think about it so it should be cleared up now. It's a minor stumbling block at best. Define opEquals and everything will work how you want. Very simple solution to a problem you seem to be blowing out of proportion. My very first post fixed your bug. Is there something stopping you from defining opEquals for the behavior you want?
Re: Stable D version?
On Tuesday, 23 April 2013 at 05:16:35 UTC, Chris Cain wrote: Actually, I'm going to strengthen this a bit more. I'd _still_ think it's a good idea to keep structs the way they are. I expect (as I think many would) structs to be very bare metal. Very little auto-magic should touch them because they are used so often for low-level tasks and you really ought to be very precise when you're defining them and their behavior. In that context, "==" being the same as "is" makes sense from my perspective and I wouldn't expect anything else unless I explicitly told it otherwise. I don't feel strongly about which path is right. But (as Mehrdad has shown) the current behaviour is not consistent either way: strings are compared bitwise, floats are compared logically.
Re: Stable D version?
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote: I suppose using "is" is more appropriate for this type of behavior. If when you see a == b you think, Hey, that's equivalent to (a.d is b.d) I suppose that when you see (a is b) you think, Hey, that's equivalent to a.d == b.d ? But calling it "broken" is a bit too strong. If it doesn't make sense, it's broken. Implementing == as 'is' by default doesn't make sense when there is already an 'is' operator that could do the same, hence it's broken.
Re: Stable D version?
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:
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.
Actually, I'm going to strengthen this a bit more. I'd _still_
think it's a good idea to keep structs the way they are. I expect
(as I think many would) structs to be very bare metal. Very
little auto-magic should touch them because they are used so
often for low-level tasks and you really ought to be very precise
when you're defining them and their behavior. In that context,
"==" being the same as "is" makes sense from my perspective and I
wouldn't expect anything else unless I explicitly told it
otherwise.
If you want some of that type of automatic "just works" behavior,
you're probably using structs as more higher level concepts.
Maybe consider using a tuple instead?
import std.stdio, std.typecons;
void main() { writeln(tuple("a") == tuple("a".idup)); }
Outputs:
true
And it's shorter and simpler than the struct example.
Re: Stable D version?
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.
Re: Stable D version?
On Tuesday, 23 April 2013 at 04:56:13 UTC, kenji hara wrote:
2013/4/23 Mehrdad
On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:
This is mostly expected behavior. During compilation value
identities are
not guaranteed.
Because compile time evaluation is always done after constant
folding, and
constant folding would fold "x".idup to "x", then S("x") ==
S("x") is
evaluated to true.
Kenji Hara
I'm not saying the 'true' is broken, I'm saying the 'false' is
broken.
And don't miss this one, which contradicts the behavior above
http://forum.dlang.org/thread/**uqkslzjnosrsnyqnhzes@forum.**
dlang.org?page=2#post-**zdmtaeycpomrhjdeanlw:40forum.**dlang.org
Ah, OK. Surely that is a compiler bug which still not fixed.
Well, I think the float behavior is correct and the string
example is broken, but that wasn't my point anyway.
The point was that it's still broken.
Re: Stable D version?
On Tuesday, 23 April 2013 at 04:48:05 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 04:43:04 UTC, Mehrdad wrote: It has nothing to do with the standard library. It should do whatever operator == does. Sounds slow. We really need a way for you to choose to have it your way and the way it is now. Oh, there's opEquals. Now we can both be happy. :) 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
Re: Stable D version?
2013/4/23 Mehrdad
> On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:
>
>>
>> This is mostly expected behavior. During compilation value identities are
>> not guaranteed.
>> Because compile time evaluation is always done after constant folding, and
>> constant folding would fold "x".idup to "x", then S("x") == S("x") is
>>
>> evaluated to true.
>>
>> Kenji Hara
>>
>
> I'm not saying the 'true' is broken, I'm saying the 'false' is broken.
>
>
> And don't miss this one, which contradicts the behavior above
> http://forum.dlang.org/thread/**uqkslzjnosrsnyqnhzes@forum.**
> dlang.org?page=2#post-**zdmtaeycpomrhjdeanlw:40forum.**dlang.org
>
Ah, OK. Surely that is a compiler bug which still not fixed.
Kenji Hara
Re: Stable D version?
In floating point value comparison, +0.0 is equal to -0.0.
auto x = +0.0;
auto y = -0.0;
assert(x == y);
Kenji Hara
2013/4/23 Mehrdad
> On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:
>
>> On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
>>
>>> ?!??!
>>>
>>
>> opEquals by default is simply a bit-level value check.
>>
>
>
>
> In fact, it's _doubly_ broken...
>
> import std.stdio;
> struct S { float d; }
> void main()
> {
> writeln(+0.0);
> writeln(-0.0);
> writeln(S(+0.0) == S(-0.0));
> }
>
>
> Output:
> 0
> -0
> true
>
Re: Stable D version?
On Tuesday, 23 April 2013 at 04:43:04 UTC, Mehrdad wrote: It has nothing to do with the standard library. It should do whatever operator == does. Sounds slow. We really need a way for you to choose to have it your way and the way it is now. Oh, there's opEquals. Now we can both be happy. :)
Re: Stable D version?
On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:
2013/4/23 Mehrdad
On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
I started a project a month ago, and for the moment my
feeling is just:
D can already be used as it.
Input:
import std.stdio;
struct S { string a; }
pragma(msg, S("x") == S("x".idup));
void main() { writeln(S("x") == S("x".idup)); }
Output:
true
false
Nope, still broken.
This is mostly expected behavior. During compilation value
identities are
not guaranteed.
Because compile time evaluation is always done after constant
folding, and
constant folding would fold "x".idup to "x", then S("x") ==
S("x") is
evaluated to true.
Kenji Hara
I'm not saying the 'true' is broken, I'm saying the 'false' is
broken.
And don't miss this one, which contradicts the behavior above
http://forum.dlang.org/thread/uqkslzjnosrsnyqnh...@forum.dlang.org?page=2#post-zdmtaeycpomrhjdeanlw:40forum.dlang.org
Re: Stable D version?
On Tuesday, 23 April 2013 at 04:37:12 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 04:33:50 UTC, Mehrdad wrote: Yeah, hence it's broken. Um... I don't see the problem. Do you expect the compiler to treat strings/arrays special and look up the equal method in the standard library? Wouldn't that confuse you when it doesn't apply to your structures? Furthermore, requiring the compiler to know about the standard library doesn't sound broken to you? It has nothing to do with the standard library. It should do whatever operator == does.
Re: Stable D version?
2013/4/23 Mehrdad
> On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
>
>> I started a project a month ago, and for the moment my feeling is just:
>> D can already be used as it.
>>
>
> Input:
> import std.stdio;
> struct S { string a; }
> pragma(msg, S("x") == S("x".idup));
> void main() { writeln(S("x") == S("x".idup)); }
>
> Output:
> true
> false
>
> Nope, still broken.
>
This is mostly expected behavior. During compilation value identities are
not guaranteed.
Because compile time evaluation is always done after constant folding, and
constant folding would fold "x".idup to "x", then S("x") == S("x") is
evaluated to true.
Kenji Hara
Re: Stable D version?
On Tuesday, 23 April 2013 at 04:33:50 UTC, Mehrdad wrote: Yeah, hence it's broken. Um... I don't see the problem. Do you expect the compiler to treat strings/arrays special and look up the equal method in the standard library? Wouldn't that confuse you when it doesn't apply to your structures? Furthermore, requiring the compiler to know about the standard library doesn't sound broken to you?
Re: Stable D version?
On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:
On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
?!??!
opEquals by default is simply a bit-level value check.
In fact, it's _doubly_ broken...
import std.stdio;
struct S { float d; }
void main()
{
writeln(+0.0);
writeln(-0.0);
writeln(S(+0.0) == S(-0.0));
}
Output:
0
-0
true
Re: Stable D version?
On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote: On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote: ?!??! I'm confused by why you might be confused by this. opEquals by default is simply a bit-level value check. Yeah, hence it's broken.
Re: Stable D version?
On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote: ?!??! I'm confused by why you might be confused by this. opEquals by default is simply a bit-level value check. "x" and "x".idup are two different things. "x" might be: ptr = 0xDEADBEEF length = 1 and "x".idup might be: ptr = 0xDEADBEEE length = 1 Clearly they are not equal. If you have a particular definition that isn't the same as the the bit-level basic equality, you have a method of defining it. For why the compiler treats them the same... well, it simply doesn't create a new place for "x".idup. Simple optimization that doesn't matter unless you're comparing their identity.
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. ?!??!
Re: Stable D version?
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.
Defining opEquals gets you the behavior you might want:
import std.stdio, std.algorithm;
struct S {
string a;
bool opEquals(S rhs) { return a.equal(rhs.a); }
}
pragma(msg, S("x") == S("x".idup));
void main() {
writeln(S("x") == S("x".idup));
}
outputs:
true
true
Re: Stable D version?
On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
I started a project a month ago, and for the moment my feeling
is just:
D can already be used as it.
Input:
import std.stdio;
struct S { string a; }
pragma(msg, S("x") == S("x".idup));
void main() { writeln(S("x") == S("x".idup)); }
Output:
true
false
...
Nope, still broken.
Re: Stable D version?
On Tuesday, 23 April 2013 at 01:06:49 UTC, eles wrote: On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote: The problem is not that D is usable or not as it is. The problem is that, until officially "handled to the user", it won't be taken too serious by the industry. In other words, you won't find jobs as a D programmer. C++ will improve more with the pending modules and other features that do not even have to wait 2014 for that (a TR will do the job). But the point here is not about C++. The problem with D is that it's never finished. Everybody waits for the next version. Everytime I spoke to my boss about D, the answer was like: "hmmm... we'll discuss about it when it's ready". D1 was killed by a under-developed phobos and by the the conflict tango-phobos, at least in part. What really killed D1 was the announcement of D2. And I have the feeling that after D2 is rolled out, people will start working on D3. That's the wrong approach. If it is usable as it is, then shift the main effort on tools for it and on promoting it. Then, let it in the market, get feedback from compiler implementors and commercial users and formalize that as a proposal for the next D standard. Then, after public scrutinize the proposed changes for 6 months or 1 tear, implement them. Only recently the focus was placed on implementing those shared libraries. Really, who'd have been expected to use D in commercial, large applications, without that support? Why did people wait for so long? Keep running circles around Optlink and other specific tools just for the sake of them? I agree they *were* valuable, but they *were*. Focus on the ldc or gcc/gdc implementation, for example. Use that as the official compiler. Do not split effort. There are a lot of standard tools that will facilitate adoption, yet the effort is misplaced. Put the current language version on the market, along with a document summarizing proposals for the future standard and get feedback from users that will start using it for real applications, on large scale. No need, for now, to make Phobos the best of the best. The curse of Tango vanished. Ship it as it is, incomplete but cleaned, then some libraries will be written and they will find almost naturally place in the standard library, just as the C++ standard integrates parts from Boost, integrated STL etc. Pursuing perfection will miss the good. I couldn't have said it better!
Re: Stable D version?
On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote: The problem is not that D is usable or not as it is. The problem is that, until officially "handled to the user", it won't be taken too serious by the industry. In other words, you won't find jobs as a D programmer. C++ will improve more with the pending modules and other features that do not even have to wait 2014 for that (a TR will do the job). But the point here is not about C++. The problem with D is that it's never finished. Everybody waits for the next version. Everytime I spoke to my boss about D, the answer was like: "hmmm... we'll discuss about it when it's ready". D1 was killed by a under-developed phobos and by the the conflict tango-phobos, at least in part. What really killed D1 was the announcement of D2. And I have the feeling that after D2 is rolled out, people will start working on D3. That's the wrong approach. If it is usable as it is, then shift the main effort on tools for it and on promoting it. Then, let it in the market, get feedback from compiler implementors and commercial users and formalize that as a proposal for the next D standard. Then, after public scrutinize the proposed changes for 6 months or 1 tear, implement them. Only recently the focus was placed on implementing those shared libraries. Really, who'd have been expected to use D in commercial, large applications, without that support? Why did people wait for so long? Keep running circles around Optlink and other specific tools just for the sake of them? I agree they *were* valuable, but they *were*. Focus on the ldc or gcc/gdc implementation, for example. Use that as the official compiler. Do not split effort. There are a lot of standard tools that will facilitate adoption, yet the effort is misplaced. Put the current language version on the market, along with a document summarizing proposals for the future standard and get feedback from users that will start using it for real applications, on large scale. No need, for now, to make Phobos the best of the best. The curse of Tango vanished. Ship it as it is, incomplete but cleaned, then some libraries will be written and they will find almost naturally place in the standard library, just as the C++ standard integrates parts from Boost, integrated STL etc. Pursuing perfection will miss the good.
Re: Stable D version?
I started a project a month ago, and for the moment my feeling is just: D can already be used as it. It's not "finished" but the state is stable enough I think. The compiler is not perfect (not always really explicit messages, not able to compile for all architecture like ARM,...), but a lot of things can already be done. I made few games on Nintendo DS console, with a pretty old gcc version on which it wasn't recommended to develop in C++ due to the lack of support of some core feature of language. Now I can just find D more advanced. C++11 and C++14 aren't really interesting for me, just cause of lack of support of some compilers like Visual Studio, it really can be the hell to realize portable applications (iOS, Android, Windows, Mac OS X, gcc, clang, cl,...). Without talking of template meta programming that are pretty hard to compile on different compilers. Because D is pretty well specified, you will never loose your time with compilers flags, missing features on a platform or macro issues before an include,... I was surprise how it's easy to progress in D just because it's fast to build and test. There is also a lot of advanced features like __traits,... that are directly in the core of language/std lib. Any IDE support D perfectly but Visual D and MonoD are just good enough for starting.
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. 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?... Radons&Minayev made a good decision to quit D back then and never look behind. A toy it was, a toy remained.
Re: Stable D version?
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
Re: Stable D version?
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote: Hi guys, I've been following the forums for a while. I'm interested in looking into D, but I understand that currently it changes often, and is not very reliable. I've also read that there's a new release model planned, where a stable version of the language is released every year or two. Is that so? When would it take place? What's holding you from releasing a version now and declaring it stable for e.g. a year? The year long support is not going to be put in place at this time. Several took issue with that plan considering it to provide limited/no benefit. The core dev team is currently getting use to using a staging branch to prepare a release. Eventually we may see a release get patched up until the point of the next release, but this has not yet been adopted by the core team or those writing patches. Having a clear understanding of what goes where has been a big point of discussion which again no one could agree on the specifics.
Stable D version?
Hi guys, I've been following the forums for a while. I'm interested in looking into D, but I understand that currently it changes often, and is not very reliable. I've also read that there's a new release model planned, where a stable version of the language is released every year or two. Is that so? When would it take place? What's holding you from releasing a version now and declaring it stable for e.g. a year?
