On Thursday, 5 February 2015 at 05:51:18 UTC, tcak wrote:
On Thursday, 5 February 2015 at 04:37:21 UTC, Tofu Ninja wrote:
On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler
wrote:
This looks very similar to std.experimental. I originally
thought that the difference between std.experimental and this
library was going to be how it was used.
std.experimental:
module that may become part of the standard libary later
your proposed library "mars"?:
modules that will probably not become a part of the standard
library. They are "addons" to the standard library. i.e.
Maybe you would like the SDL library, but it doesn't make
sense to include in the standard library because it it not
useful to everyone. For these kinds of libraries it would be
nice to have a set of community supported libraries that
shouldn't be in the standard library but are still useful to
a subset of the community.
However, it appears that this proposal is just another
version of std.experimental.
This is what I originally though as well. Personally I think
what you just described would be much more useful. It really
feels like this is just another std.experimental with only
subtle distinctions. I don't think it adds much value.
For me, this experimental thing is a problem due to the fact
that release period of DMD is too long. Experimental means
there will be lots of changes. A programmer shouldn't be
waiting to get new versions of experimental codes.
What could be great is if DMD supported something like JAR
packages, and could look for modules inside of them. So, all
experimental codes would be packed daily in a zip file, and any
programmer, with only download of a single file and including
it on command line while compiling, would have latest code very
quickly.
or std.experimental could just be separated into its own
repository and put on dub?
