Building JSON until 2.067
I'm trying to build a small utility for a project at work that stores some config on-disk as JSON. Imagine my dismay when I find that opIndexAssign hasn't been added to JSONValue until after 2.066 went out: https://github.com/D-Programming-Language/phobos/pull/2607 1. Is there any way until 2.067 gets release to build a JSON object, besides building it as a string? 2. I'm thoroughly confused - something like this would make it seem that std.json is almost never used "in the wild". Is there a JSON library that most other people are using instead?
Range functions expand char to dchar
After seeing Walter's DConf presentation from this year, I've
been making an effort to use range algorithms more, such as using
chain() and joiner() as an alternative to array concatenation and
std.array.join.
Unfortunately, doing so with strings has been problematic, as
these algorithms expand strings into dstrings.
An example:
import std.algorithm;
import std.range;
import std.stdio;
import std.regex;
void main()
{
// One would expect this to be a range of chars
auto test = chain("foo", "bar", "baz");
// prints "dchar"
writeln(typeid(typeof(test.front)));
auto arr = ["foo", "bar", "baz"];
auto joined = joiner(arr, ", ");
// Also "dchar"
writeln(typeid(typeof(joined.front)));
// Problems ensue if one assumes the result of joined is a
char string.
auto r = regex(joined);
matchFirst("won't compile", r); // Compiler error
}
Whether by design or by oversight, this is quite undesirable. It
violates the principle of least astonishment (one wouldn't expect
joining a bunch of strings would result in a dstring), causing
issues such as the one shown above. And, if I aim to use UTF-8
consistently throughout my applications (see
http://utf8everywhere.org/), what am I to do?
Re: Range functions expand char to dchar
On Tuesday, 8 September 2015 at 17:52:13 UTC, Matt Kline wrote: Whether by design or by oversight, this is quite undesirable. My apologies for double-posting, but is this intended behavior, or an unfortunate consequence of the metaprogramming used to determine the resulting type of these range functions?
Re: Range functions expand char to dchar
On Tuesday, 8 September 2015 at 18:21:34 UTC, anonymous wrote:
By design with regrets:
http://forum.dlang.org/post/m01r3d$1frl$1...@digitalmars.com
On Thursday, 25 September 2014 at 19:40:29 UTC, Walter Bright
wrote:
Top of my list would be the auto-decoding behavior of
std.array.front() on character arrays. Every time I'm faced
with that I want to throw a chair through the window.
At least I'm not alone. :)
You can use std.utf.byCodeUnit to get ranges of chars:
A bit verbose, but I suppose that will do.
/* Having char elements isn't enough. Need to turn the
range into an
array via std.array.array: */
auto r = regex(joined.array);
matchFirst("won't compile", r); /* compiles */
}
If we have a range of char elements, won't that do? regex() uses
the standard isSomeString!S constraint to take any range of chars.
Re: DoxyPress support for D
On Tuesday, 13 October 2015 at 08:48:14 UTC, Ali Çehreli wrote: - Since D already has ddoc, do we need DoxyPress support as well? While ddoc is great (just by virtue of being there by default), Doxygen (and by extension DoxyPress) have some really nice features that are sorely missed when I'm using ddoc. Its cross-referencing, dependency graph, and annotated code abilities beat out every other "auto" documentation system I've used. I've used it often in the past on Java and C# projects, in spite of the dedicated doc tools those languages have (JavaDoc and Visual Studio's XML comment system, respectively). I'd use it in an instant if it could parse D and ddoc-style comments. - If so, who would like to help Barbara and Ansel? :) If only there were more hours in the day...
Understanding the D memory model re: Voldemort types
I have a bit of confusion about the D memory model when it comes
to returning nested classes (i.e. "Voldemort types") and am
hoping someone can take a minute to clear it up. Consider the
following short program:
auto foo()
{
import std.random;
import std.conv;
auto i = dice(0.5, 0.5);
string s = "Hello, scopes";
class Bar {
string what() { return s ~ " " ~ i.to!string; }
}
return new Bar;
}
void main()
{
import std.stdio;
auto b = foo();
writeln(b.what());
}
I was under the impression that nested classes captured their
context via a pointer to the current stack frame. But if that
were the case, reading i and s when b.what() is called would
cause invalid reads below the current stack pointer, and this
data could be thrashed by inserting any calls between the call to
foo() and the call to b.what(). Running the above program through
valgrind also indicates no foul play.
So what is actually going on here? Do nested classes capture
their context some other way? Does the compiler do semantic
analysis and capture local variables by value if an instance of
the Voldemort type is going to get returned out of the function?
Re: Understanding the D memory model re: Voldemort types
On Thursday, 9 April 2015 at 18:15:16 UTC, H. S. Teoh wrote: The compiler detects when a variable is being closed over by a nested function, and allocates them on the heap instead of the stack. Is there somewhere I can read more about this (besides the compiler source code)? What ramifications are there for local variables being closed over that have destructors? Does the Voldemort object then get implicit destructor code that destroys the closed-over variables when it falls out of scope?
