Re: Blog post : OOP composition with mixins
On 2015-08-31 14:20:23 +, Abdulhaq said: Inheritance certainly is 'the base class of all evil'. I have a theory that the reason inheritance is so overused in OOP languages lies in the way it is taught - the OOP aspects cover much of the syntax of the language and hence much teaching material revolves around inheritance. This makes the student believe that inheritance is therefore the 'right way' to proceed. I think what's missing is, that inheritance should be used with a type-system view in mind. It makes sense to model "typed things" but not to model functionallity / re-using of functionallity. This is much bettern done with a concept like mixins. And mixing both is a very powerful way to model complex system. You "just" need to know when to use one or the other. Many years of pain have, however, taught me to avoid inheritance and to prefer composition - even/especially when using e.g. Java. Because all those OOP languages are to dogmatic about it's use. C++ is free, but is missing (not sure if still) the template and mixin power of D. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Beta D 2.068.1-b2
On Tue, Sep 1, 2015 at 8:34 AM, Jacob Carlborg via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On 2015-08-31 08:01, Martin Nowak wrote: > >> First beta for the 2.068.1 point release (we skipped -b1 due to a bug). >> > > Here's a piece of code that used to compile in 2.067.0 but not in 2.068.0: > > class UniText > { > abstract const char[] toString (char[] dst = null); > abstract const wchar[] toString16 (wchar[] dst = null); > abstract const dchar[] toString32 (dchar[] dst = null); > } > > The error message is: > > Error: class main.UniText use of object.Object.toString() is hidden by > UniText; use 'alias toString = Object.toString;' to introduce base class > overload set > > I suspect this is intended? > > -- > /Jacob Carlborg > Yep, that is intended. You have to explicitly "import" overload sets. It does seem to me that if there is only one function in the other overload set the error could be disabled, however it is clearer the way it works in 2.068. And it will get us used to having to be explicit when adding to overload sets like in the code above.
Re: Dynamic arrays
On Monday, 31 August 2015 at 22:03:07 UTC, jmh530 wrote: In general, I find myself very easily getting mixed up by the syntax of the static vs. dynamic arrays. For instance, compare int[] x = new int[3]; int[3] y = new int[3]; auto z = new int[3]; x and y are obviously dynamic and static arrays, respectively. However, my initial guess on z is that is like y, a static array on the heap. But that is wrong. It's actually like x. Easy to get confused. In general, "new" means heap allocation. I wonder about the initialization of y. Maybe it creates a temporary dynamic array on the heap and then copies it to the static array on the stack?
Re: v0.2.1 of EMSI's containers library
On Tuesday, 1 September 2015 at 04:03:48 UTC, Brian Schott wrote: https://github.com/economicmodeling/containers This containers library is built on top of Andrei's std.experimental.allocator. It's currently used by libraries internal to EMSI, as well as the open-source DCD project. Great!
Re: v0.2.1 of EMSI's containers library
On Tuesday, 1 September 2015 at 04:03:48 UTC, Brian Schott wrote: https://github.com/economicmodeling/containers Could the test (plot) be extended to show insertion performance for different allocators :)
Re: Dynamic arrays
On 09/01/2015 12:43 AM, qznc wrote: On Monday, 31 August 2015 at 22:03:07 UTC, jmh530 wrote: In general, I find myself very easily getting mixed up by the syntax of the static vs. dynamic arrays. For instance, compare int[] x = new int[3]; int[3] y = new int[3]; auto z = new int[3]; x and y are obviously dynamic and static arrays, respectively. However, my initial guess on z is that is like y, a static array on the heap. But that is wrong. It's actually like x. Easy to get confused. In general, "new" means heap allocation. I wonder about the initialization of y. Maybe it creates a temporary dynamic array on the heap and then copies it to the static array on the stack? Seems to be so: import std.stdio; void main() { int[] x = new int[3]; int[3] y = new int[3]; auto z = new int[3]; writeln(x.ptr); writeln(y.ptr); writeln(z.ptr); } y's elements are on the stack: 7F1375618200 7FFF091A9910 7F1375618220 Ali
Re: Blog post : OOP composition with mixins
On Monday, 24 August 2015 at 11:10:16 UTC, Dicebot wrote: Rough summary of the talk I have given for recent Berlin D meetup event: https://blog.dicebot.lv/posts/2015/08/OOP_composition_with_mixins I'm having trouble resolving that DNS name.
Re: D-Day for DMD is today!
On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: We have made the switch from C++ DMD to D DMD! Is there a rough prediction of when the use of phobos in ddmd will start to be accepted?
Re: Blog post : OOP composition with mixins
On Tuesday, 1 September 2015 at 10:18:08 UTC, Luís Marques wrote: On Monday, 24 August 2015 at 11:10:16 UTC, Dicebot wrote: Rough summary of the talk I have given for recent Berlin D meetup event: https://blog.dicebot.lv/posts/2015/08/OOP_composition_with_mixins I'm having trouble resolving that DNS name. Technical server issues, should be back now.
Re: D-Day for DMD is today!
On 9/1/15 6:48 AM, "Luís Marques wrote: On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: We have made the switch from C++ DMD to D DMD! Is there a rough prediction of when the use of phobos in ddmd will start to be accepted? I'm not a dmd dev, but I'm not sure it will be accepted, since phobos is very unstable. We have to be cautious about making dmd breakable easily by a change to phobos. Of course, I think there is a baseline dmd/gdc/ldc that must be used to build dmd, so perhaps as long as you use phobos features that work there, it will be OK. -Steve
Re: Blog post : OOP composition with mixins
On Tuesday, 1 September 2015 at 11:36:49 UTC, Dicebot wrote: On Tuesday, 1 September 2015 at 10:18:08 UTC, Luís Marques wrote: On Monday, 24 August 2015 at 11:10:16 UTC, Dicebot wrote: Rough summary of the talk I have given for recent Berlin D meetup event: https://blog.dicebot.lv/posts/2015/08/OOP_composition_with_mixins I'm having trouble resolving that DNS name. Technical server issues, should be back now. BTW, a bit HS but in your article about Rust (https://blog.dicebot.lv/posts/2015/01/thoughts_about_rust_from_d_programmer) there is a “” lying in the first example.
Re: Beta D 2.068.1-b2
On 9/1/15 2:34 AM, Jacob Carlborg wrote: On 2015-08-31 08:01, Martin Nowak wrote: First beta for the 2.068.1 point release (we skipped -b1 due to a bug). Here's a piece of code that used to compile in 2.067.0 but not in 2.068.0: class UniText { abstract const char[] toString (char[] dst = null); abstract const wchar[] toString16 (wchar[] dst = null); abstract const dchar[] toString32 (dchar[] dst = null); } The error message is: Error: class main.UniText use of object.Object.toString() is hidden by UniText; use 'alias toString = Object.toString;' to introduce base class overload set I suspect this is intended? I'm not 100% sure, but that does seem like a bug. You should be able to completely mask toString from a base class if you don't specify override IMO. I'm assuming the minimal case is just toString? -Steve
Re: v0.2.1 of EMSI's containers library
On Tuesday, 1 September 2015 at 04:03:48 UTC, Brian Schott wrote: https://github.com/economicmodeling/containers The link to documentation doesn't seem to have anything on it.
Re: Blog post : OOP composition with mixins
On Monday, 24 August 2015 at 11:10:16 UTC, Dicebot wrote: Rough summary of the talk I have given for recent Berlin D meetup event: https://blog.dicebot.lv/posts/2015/08/OOP_composition_with_mixins Are you planning on submitting this article to Reddit/Hacker News?
Re: D-Day for DMD is today!
On Tue, Sep 1, 2015 at 3:44 PM, Steven Schveighoffer via Digitalmars-d-announce wrote: > [snip] > I'm not a dmd dev, but I'm not sure it will be accepted, since phobos is > very unstable. We have to be cautious about making dmd breakable easily by > a change to phobos. > [snip] -Steve > Surely this is a code coverage issue then? Are there any unit tests in ddmd?
Re: D-Day for DMD is today!
On 1 September 2015 at 15:57, Rory McGuire via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Tue, Sep 1, 2015 at 3:44 PM, Steven Schveighoffer via > Digitalmars-d-announce wrote: > >> [snip] >> I'm not a dmd dev, but I'm not sure it will be accepted, since phobos is >> very unstable. We have to be cautious about making dmd breakable easily by >> a change to phobos. >> [snip] > > -Steve >> > > Surely this is a code coverage issue then? > Are there any unit tests in ddmd? > >From how I see it, Phobos is constantly adding, silently breaking, deprecating, and removing. We need long term backwards compatibility, and Phobos just doesn't fit in that picture (yet).
Re: D-Day for DMD is today!
On Tuesday, 1 September 2015 at 14:33:47 UTC, Iain Buclaw wrote: deprecating, and removing. We need long term backwards compatibility, and Phobos just doesn't fit in that picture (yet). Why do you need long term backwards compatibility?
Re: Blog post : OOP composition with mixins
On Tuesday, 1 September 2015 at 13:44:15 UTC, cym13 wrote: BTW, a bit HS but in your article about Rust (https://blog.dicebot.lv/posts/2015/01/thoughts_about_rust_from_d_programmer) there is a “” lying in the first example. Thanks, fixed.
Re: Blog post : OOP composition with mixins
On Tuesday, 1 September 2015 at 14:11:44 UTC, Meta wrote: On Monday, 24 August 2015 at 11:10:16 UTC, Dicebot wrote: Rough summary of the talk I have given for recent Berlin D meetup event: https://blog.dicebot.lv/posts/2015/08/OOP_composition_with_mixins Are you planning on submitting this article to Reddit/Hacker News? There is something wrong about submitting own articles into aggregators :) Feel free to do so if you want to.
Re: D-Day for DMD is today!
On Tuesday, 1 September 2015 at 14:52:09 UTC, Adam D. Ruppe wrote: On Tuesday, 1 September 2015 at 14:39:57 UTC, Ola Fosheim Grøstad wrote: Why do you need long term backwards compatibility? It would be nice for bootstrapping... now that we need dmd to build dmd, it'd be really annoying if you need to install version X-3 to compile version X-2 to compile X-1 to finally compile version X just because of some stdlib instability. Don't forget about differences in FE versions between dmd/ldc/gdc - and the fact you want distribute most performant build possible.
Re: D-Day for DMD is today!
On Tuesday, 1 September 2015 at 14:39:57 UTC, Ola Fosheim Grøstad wrote: Why do you need long term backwards compatibility? It would be nice for bootstrapping... now that we need dmd to build dmd, it'd be really annoying if you need to install version X-3 to compile version X-2 to compile X-1 to finally compile version X just because of some stdlib instability.
Re: D-Day for DMD is today!
On Tuesday, 1 September 2015 at 14:52:09 UTC, Adam D. Ruppe wrote: On Tuesday, 1 September 2015 at 14:39:57 UTC, Ola Fosheim Grøstad wrote: Why do you need long term backwards compatibility? It would be nice for bootstrapping... now that we need dmd to build dmd, it'd be really annoying if you need to install version X-3 to compile version X-2 to compile X-1 to finally compile version X just because of some stdlib instability. If that is an issue (I am not sure I understand why that scenario would arise) can't you pick a version of Phobos and make it part of the distribution, or mark some parts of Phobos stable and others unstable? I assume such stability issues also are relevant for commercial projects, not only DMD. Seems to me that the most important advantage of moving to D is to attract developers that are unfamiliar with C++, so using selected parts of Phobos would make it a lot easier and fun for them to contribute. I assume refactoring, high quality documentation and perhaps a tutorial too, of course. Seems to me that lowering the "anxiety threshold" could be an important move.
Re: Blog post : OOP composition with mixins
On Tuesday, 1 September 2015 at 14:32:11 UTC, Dicebot wrote: On Tuesday, 1 September 2015 at 14:11:44 UTC, Meta wrote: On Monday, 24 August 2015 at 11:10:16 UTC, Dicebot wrote: Rough summary of the talk I have given for recent Berlin D meetup event: https://blog.dicebot.lv/posts/2015/08/OOP_composition_with_mixins Are you planning on submitting this article to Reddit/Hacker News? There is something wrong about submitting own articles into aggregators :) Feel free to do so if you want to. Sounds good to me. https://www.reddit.com/r/programming/comments/3j8bi2/oop_composition_with_mixins_in_the_d_programming/
Re: D-Day for DMD is today!
On Tuesday, 1 September 2015 at 15:02:37 UTC, Ola Fosheim Grøstad wrote: Seems to me that the most important advantage of moving to D is to attract developers that are unfamiliar with C++, so using selected parts of Phobos would make it a lot easier and fun for them to contribute. I assume refactoring, high quality documentation and perhaps a tutorial too, of course. Seems to me that lowering the "anxiety threshold" could be an important move. Exactly. I was surprised to find out I couldn't use Phobos in ddmd. Raw D is still more pleasant than programming in C++, but not nearly as much fun as writing normal D code.
Re: Beta D 2.068.1-b2
On 2015-09-01 15:40, Steven Schveighoffer wrote: I'm not 100% sure, but that does seem like a bug. You should be able to completely mask toString from a base class if you don't specify override IMO. Hmm, I'm not sure. This overloads toString. I'm assuming the minimal case is just toString? Yes. -- /Jacob Carlborg
Re: Beta D 2.068.1-b2
On 2015-09-01 15:40, Steven Schveighoffer wrote: I'm not 100% sure, but that does seem like a bug. I see now that there's a deprecation message when compiling with 2.067.0. So it looks like it's intended. -- /Jacob Carlborg
Re: Beta D 2.068.1-b2
On 2015-09-01 15:40, Steven Schveighoffer wrote: I'm not 100% sure, but that does seem like a bug. You should be able to completely mask toString from a base class if you don't specify override IMO. Perhaps we need an explicit way to tell the compile we want to hide a method in the base class. C# uses the "new" keyword for this if I recall correctly. -- /Jacob Carlborg
Re: Dynamic arrays
On Monday, August 31, 2015 21:36:17 John Colvin via Digitalmars-d-announce wrote: > On Monday, 31 August 2015 at 21:29:09 UTC, anonymous wrote: > > On Monday 31 August 2015 23:09, Minas Mina wrote: > > > >> I have started a series of tutorials in D. > >> > >> This is my latest blog post, which is about dynamic arrays: > >> http://minas-mina.com/2015/08/31/dynamic-arrays/ > >> > >> Constructive criticism is welcome. > > > > "Dynamic arrays are allocated on the garbage collected heap" > > "Dynamic arrays can be sliced" > > > > These are not wrong, but maybe a little bit misleading. > > > > Static arrays and pointers can be sliced, too. And a slice of a > > static array or pointer is ... dramatic pause ... a dynamic > > array that doesn't necessarily refer to the GC heap. > > I prefer the term "slice" to dynamic array. Because it's an > unfamiliar term it helps prevent confusion for people who are > used to what other languages call dynamic arrays. Per the spec, T[] is a dynamic array no matter what backs it. And slice is a _heavily_ overloaded term in D - e.g. you slice a range, and you get another range, not necessarily a dynamic array. If you slice a container, you get a range, not a container or a dynamic array. Steven's article uses the wrong terminology (at least as for as the spec is concerned), which I wish it didn't, since I think that that causes other kinds of confusion, and it has led folks to use the term slice when the official term is dynamic array, but his article has gone a long way to explaining D's dynamic arrays to people, and we're very much better off for it. But there is no non-overloaded term to use here, and I think that folks get overly hung up over the difference between T[] as a struct and the memory that it refers to. The semantics of the code generally don't care what's backing the dynamic array. It's a dynamic array regardless of what memory backs it, and you can do the same operations on it either way. What changes is the lifetime of the memory that it refers to. Everything else is the same. All of the operations which involve allocation or checking for free space for the dynamic array to grow into work regardless of whether the memory that it refers to is GC-allocated or not. And since you can't know whether the memory is going to be reallocating when appending without checking the capacity, the fact that any memory that isn't GC-allocated is guaranteed to reallocate when appending doesn't change much. A GC-backed dynamic array could have end up with reallocated memory just as easily. You have to check the capacity to know. And the semantics are really the same whether the memory backing the dynamic array is GC-allocated or not. So really, what it comes down to is how the lifetime of a dynamic array's memory is managed, and it's _not_ the dynamic array that's doing the managing regardless of what memory is backing it. If it was GC-allocated, then it's the GC, whereas if it were malloced, then your code needs to keep track of it elsewhere, and if it was sliced from a static array, then you need to make sure that the dynamic array doesn't outlive the static one. So, if the dynamic array is referring to non-GC allocated memory, then you need to be careful in order to make sure that the dynamic array doesn't outlive the memory that it refers to, but all of the operations are the same either way. So, I honestly think that the focus on the GC-allocated buffers that dynamic arrays usually refer to actually confuses people at least some of the time. If you want to manage the memory efficiently, then you need to understand how that works, and you need to understand which operations will talk to the GC and which _might_ cause allocations so that you can avoid unnecessary communication with the GC and avoid having code that assumes that two dynamic arrays refer to the same memory when they don't. But the dynamic arrays themselves really don't care what backs them, and aside from making sure that you manage the lifetime of that memory properly when it's not GC-allocated, the code that uses dynamic arrays really doesn't care what's backing them. - Jonathan M Davis
Re: v0.2.1 of EMSI's containers library
On Tuesday, 1 September 2015 at 13:51:45 UTC, jmh530 wrote: The link to documentation doesn't seem to have anything on it. The package name on the left is expandable.
DCD 0.7.0
https://github.com/Hackerpilot/DCD/tree/v0.7.0 After an alpha, a beta, and two release candidates DCD 0.7.0 is ready. The D Completion Daemon is an auto-complete program for the D programming language. Highlights: * A large portion of DCD's symbol resolution engine was removed and placed into the new dsymbol project. * Several design bugs with the cache invalidation process were fixed. (TLA+ was helpful with this) * Regression testing! DCD now has regression tests. This was long overdue... Information on the tests can be found on the testing wiki page * DCD now uses the latest version of std.experimental.allocator. * Added the ability to ask the client to list the paths that are registered with the server. * Removed all editor plugins from the DCD repository. All editor plugins were maintained outside of this repository anyways, so this was more-or-less a dead code removal. Links to editor plugins and IDEs can be found on the wiki * Support 2.068 syntax. The only thing that really changed is that "inline" and "mangle" are now on the list of "pragma" autocomplete suggestions. * Add "__LINE__", "__FILE__", and other built-in symbols to autocomplete suggestions. * Correctly expand the current working directory when starting the server with -I options specifying relative paths. * Fixed many bugs: https://github.com/Hackerpilot/DCD/issues?q=milestone%3A0.7.0
LLVM 3.7 released - LDC is ready to use it!
Hi all! LLVM 3.7 has been released some minutes ago! See the release notes here: http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html Downloads: http://llvm.org/releases/download.html#3.7.0 Also note that LDC is mentioned in the release notes as one of the projects who are already supporting LLVM 3.7. Just recompile LDC using master/merge-2.067 branch from GitHub. This is the 7th time that LDC and D are mentioned in the LLVM release notes! Regards, Kai
Re: DCD 0.7.0
On Tuesday, 1 September 2015 at 21:36:46 UTC, Brian Schott wrote: https://github.com/Hackerpilot/DCD/tree/v0.7.0 After an alpha, a beta, and two release candidates DCD 0.7.0 is ready. Thx, awesome release.
LDC 0.16.0 alpha2 is out!
Hi everyone, LDC 0.16.0 alpha2, the LLVM-based D compiler, is available for download! This release is based on the 2.067.1 frontend and standard library and supports LLVM 3.1-3.7 (OS X: no support for 3.3). Don't miss to check if your preferred system is supported by this release. There is even an alpha-quality Win64 version available! As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/qvxvcpceknfzsizbt...@forum.dlang.org Regards, Kai
Re: LLVM 3.7 released - LDC is ready to use it!
On Tue, 01 Sep 2015 21:45:30 +, Kai Nacke wrote: > This is the 7th time that LDC and D are mentioned in the LLVM release > notes! Fantastic work keeping LDC bleeding edge!
Re: v0.2.1 of EMSI's containers library
On Tuesday, 1 September 2015 at 20:58:45 UTC, Brian Schott wrote: On Tuesday, 1 September 2015 at 13:51:45 UTC, jmh530 wrote: The link to documentation doesn't seem to have anything on it. The package name on the left is expandable. D'oh
Re: v0.2.1 of EMSI's containers library
On Tuesday, 1 September 2015 at 08:05:34 UTC, Per Nordlöw wrote: On Tuesday, 1 September 2015 at 04:03:48 UTC, Brian Schott wrote: https://github.com/economicmodeling/containers Could the test (plot) be extended to show insertion performance for different allocators :) I could do that but I won't because I'd rather work on other things. I will tell you, however, that you can destroy the performance advantage these containers have by having the allocator create 1k blocks instead of 16 blocks. I think that this demonstrates that using std.experimental.allocator gives users several high-impact ways to optimize their programs.
Re: v0.2.1 of EMSI's containers library
On Tuesday, 1 September 2015 at 23:13:09 UTC, Brian Schott wrote: instead of 16 blocks That should be "16k blocks".
Re: D-Day for DMD is today!
On Tuesday, September 01, 2015 09:44:17 Steven Schveighoffer via Digitalmars-d-announce wrote: > On 9/1/15 6:48 AM, "Luís Marques wrote: > > On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: > >> We have made the switch from C++ DMD to D DMD! > > > > Is there a rough prediction of when the use of phobos in ddmd will start > > to be accepted? > > I'm not a dmd dev, but I'm not sure it will be accepted, since phobos is > very unstable. We have to be cautious about making dmd breakable easily > by a change to phobos. > > Of course, I think there is a baseline dmd/gdc/ldc that must be used to > build dmd, so perhaps as long as you use phobos features that work > there, it will be OK. Plenty of Phobos is stable and hasn't changed in quite a while. We do sometimes deprecate stuff still, but there isn't much that gets deprecated at this point, and the deprecation cycle is about two years. The common problem would be regressions, and the compiler gets those as much or more often than Phobos does. But it is true that some stuff in Phobos changes occasionally, and that could affect how new a compiler you need to compile the current dmd. Regardless of that though, I know that at least some of the dmd developers are against using Phobos simply because they don't want the dependency. It simplifies things if Phobos isn't in the mix. If you have to track down and fix a regression in the compiler, that's easier to do if you don't have to worry about the standard library being in the mix. The less that the compiler depends on, the less that the compiler devs have to worry about affecting the compiler. And if we need anything to be sure of anything working right, it's the compiler. Sure, there are some things in the standard library that might be nice to use in the compiler, but that doesn't mean that it's necessarily worth pulling in Phobos as a dependency, and if it's something that's really useful, maybe it's worth duplicating in the compiler code - or even making a version of it that's tailored to the compiler's needs. - Jonathan M Davis
Re: LLVM 3.7 released - LDC is ready to use it!
On Tuesday, 1 September 2015 at 21:45:32 UTC, Kai Nacke wrote: Hi all! LLVM 3.7 has been released some minutes ago! See the release notes here: http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html Downloads: http://llvm.org/releases/download.html#3.7.0 Also note that LDC is mentioned in the release notes as one of the projects who are already supporting LLVM 3.7. Just recompile LDC using master/merge-2.067 branch from GitHub. This is the 7th time that LDC and D are mentioned in the LLVM release notes! Nice. Emulated TLS for ELF was added in llvm 3.7, looking forward to trying that on Android, which doesn't have native TLS.
Re: D-Day for DMD is today!
On 2 Sep 2015 5:31 am, "Jonathan M Davis via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > On Tuesday, September 01, 2015 09:44:17 Steven Schveighoffer via Digitalmars-d-announce wrote: > > On 9/1/15 6:48 AM, "Luís Marques wrote: > > > On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: > > >> We have made the switch from C++ DMD to D DMD! > > > > > > Is there a rough prediction of when the use of phobos in ddmd will start > > > to be accepted? > > > > I'm not a dmd dev, but I'm not sure it will be accepted, since phobos is > > very unstable. We have to be cautious about making dmd breakable easily > > by a change to phobos. > > > > Of course, I think there is a baseline dmd/gdc/ldc that must be used to > > build dmd, so perhaps as long as you use phobos features that work > > there, it will be OK. > > Plenty of Phobos is stable and hasn't changed in quite a while. We do > sometimes deprecate stuff still, but there isn't much that gets deprecated > at this point, and the deprecation cycle is about two years. The common > problem would be regressions, and the compiler gets those as much or more > often than Phobos does. But it is true that some stuff in Phobos changes > occasionally, and that could affect how new a compiler you need to compile > the current dmd. > Don't forget, Phobos library maintainers love to use new features everywhere. Tagging many functions with @nogc almost weeks after it was introduced in master was the last major backwards breaking change you did that I'm aware of. Iain.