<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lang.d.general">
    <title>gmane.comp.lang.d.general</title>
    <link>http://blog.gmane.org/gmane.comp.lang.d.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/118177"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/118173"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/118112"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/118057"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/118034"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/118031"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117921"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117897"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117879"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117877"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117876"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117867"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117856"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117854"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117848"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117827"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117763"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117746"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117721"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/117718"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/118177">
    <title>External lib unittests: they're killin me!</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/118177</link>
    <description>&lt;pre&gt;Y'know what we need? This compiler flag:

   -unittest=pagkage.name.*

Damn near every codebase in D uses "unittest{}" sections. Obviously
that's good.

But it's also bad:

I cannot flip on unittests for my project (where "I" and "my" can be
substituted with the name of any D user) without *also* flipping on
unittests for every source-library used, transitively. Unless the lib
versions-out their unittests with "version(Unittest_MyLibXXX)"...And
none of them do. (well, mostly)

This *can* be fine, *when*:

- They're all fast.

- Their sum doesn't make DMD's memory usage go kabloom.

- They all have all their prereqs already setup (sometimes the need for
  some configuration isn't easily avoidable, example: setting up a DB
  user/login).

- And none of them have any failures...on the *exact*
  OS/arch/compiler/compiler-version combination that I happen to be
  using. Oh, and the exact versions of any other dependent libs.

We could say "Let's just recommend good style is to version out your
unittest blocks". B&lt;/pre&gt;</description>
    <dc:creator>Nick Sabalausky</dc:creator>
    <dc:date>2013-05-21T01:52:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/118173">
    <title>support UFCS with fully qualified function names (was in"digitalmars.D.learn")</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/118173</link>
    <description>&lt;pre&gt;(I've re-posting here upon request from bearophile, who seems to like it :)
)

I'd like to be able to use UFCS with fully qualified function names.

A typical use case is to disambiguate , as in the following case:

import std.path;
import std.string;
void main(){
    //Error: std.path.join()(const(char)[] p1, const(char)[] p2, const(char[
])[] more...) at ... conflicts with std.string.join at ...
    auto a="".join("\n");
    //what I'd like to have:
    auto a="".(std.path.join)("\n");
}

note: the fact that std.path.join!().join is deprecated is irrelevant to
this discussion.

Any chance this could be supported?

benefits:
avoids breaking UFCS chains
&lt;/pre&gt;</description>
    <dc:creator>Timothee Cour</dc:creator>
    <dc:date>2013-05-21T01:28:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/118112">
    <title>Range for files by character</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/118112</link>
    <description>&lt;pre&gt;Hi,

I need an Input Range that iterates a file character by 
character. In bioinformatics this is often important, and having 
a D-range is of course preferable than any foreach-byLine 
combination, since we can apply filters and other goodies from 
std.algorithm. In this implementation, I am simply filtering out 
new-lines, as an example.

import std.stdio;
import std.conv;
import std.algorithm;

void main() {
   auto f = File("someFile.txt", "r");
   foreach(c; f.byChunk(1).filter!(a =&amp;gt; to!char(a[0]) != '\n'))
     write(to!char(c[0]));
}

Is this the right way to do it? I was a bit surprised that 
std.stdio doesn't provide a "byChar" or "byByte" range. Is there 
a reason for this, or is this a too special need?

Stephan

&lt;/pre&gt;</description>
    <dc:creator>Stephan Schiffels</dc:creator>
    <dc:date>2013-05-20T21:36:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/118057">
    <title>opDispatch and operator overloads</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/118057</link>
    <description>&lt;pre&gt;struct S {
auto opDispatch(string s)(A i){}
}

struct A {}

void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
}

It would be really nice if opDispatch could catch missing 
operator overloads.

Also, would it be a good idea to have free functions of all the 
operators (opOpAssign etc...) for builtin types somewhere? It's 
occasionally useful in generic wrappers.

&lt;/pre&gt;</description>
    <dc:creator>John Colvin</dc:creator>
    <dc:date>2013-05-20T15:15:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/118034">
    <title>Vote for std.uni</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/118034</link>
    <description>&lt;pre&gt;This is a replacement module for the current std.uni by Dmitry 
Olshansky. The std.uni module provides an implementation of 
fundamental Unicode algorithms and data structures.

If you would like to see the proposed std.uni include into Phobos 
please vote yes. If one condition must be met specify under what 
condition, otherwise vote no.

In summary, most discussion revolved around the string based 
functions for toLower/toUpper and where they should live.

Please place any further comments in the official review thread 
leaving only your vote and a short comment (there should be no 
need to reply to anyone).

Docs:
http://blackwhale.github.io/phobos/uni.html

Source:
https://github.com/blackwhale/phobos/tree/new-std-uni
Stand Alone: https://github.com/blackwhale/gsoc-bench-2012

Review Thread:
http://forum.dlang.org/post/xbuphdghoyymjajpfzki&amp;lt; at &amp;gt;forum.dlang.org

Sunday April 26 PST will be the last day of voting.

&lt;/pre&gt;</description>
    <dc:creator>Jesse Phillips</dc:creator>
    <dc:date>2013-05-20T06:18:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/118031">
    <title>Ideal D GUI Toolkit</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/118031</link>
    <description>&lt;pre&gt;I've been looking into trying to fix QtD, but it seems writing a 
binding to a C++ library is a bit complicated. I've read on the 
forums that a native D GUI toolkit is the most desirable 
long-term, so I'd like to start that discussion.

First off, I've heard of the DWT project, which looks promising, 
but it seems like a direct port of Java's SWT instead of a 
reimagining using idiomatic D. I understand the allure here 
(works, little translation for new developers), but since it's 
not yet in Phobos, I can only assume it's still up for discussion.

Personally, I want these features:

* simple and extensible
   * minimal components (something like HTMLs feature-set)
   * custom components (embed OpenGL/direct frame buffer)
* "native" window decorations by default, but can provide custom 
decorations
* markup (like QML) or programmable (like SWT)

Nice-to-haves:

* hardware accelerated (2D OpenGL)
* GUI designer (much easier with QML-esque markup)
* part of Phobos

I'm willing to lend a hand, but I'd like t&lt;/pre&gt;</description>
    <dc:creator>Tyler Jameson Little</dc:creator>
    <dc:date>2013-05-20T05:25:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117921">
    <title>Operators overloading</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117921</link>
    <description>&lt;pre&gt;Hello from France everyone ! (I hope my english will be 
readable...)

Yesterday, I discover D and that was really really great. I am 
far from being a guru (it seems there are a lot here ;-) but I 
foud the language clear and expressive the documentation is very 
well done futhermore dmd is incredibly fast and the logs are pure 
awesomness (a gcc command often doesn't fit on my shell). I know 
you are waiting for a 'but' and there is one : it's about 
operators overloading. First, but that kind of ok with me, I 
don't like the syntax :

const Vertex opBinary(string op)(const ref Vertex vertex)
if (op == "+" || op == "-")
{
Vertex result = *this;
mixin("result" ~ op ~ "= vertex;");
return result;
}

I don't like the 'if' outside and the condition could be really 
long : if (op == "+" || op == "-" || op == "*" || op == "/"). 
Okay, putting the if inside is quite easy :

const Vertex opBinary(string op)(const ref Vertex vertex)
{
static if if (op == "+" || op == "-")
{
Vertex result = *th&lt;/pre&gt;</description>
    <dc:creator>matovitch</dc:creator>
    <dc:date>2013-05-19T07:32:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117897">
    <title>C++ constructors, destructors and operator access</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117897</link>
    <description>&lt;pre&gt;At the current time D have powerful mechanism of access to C++ 
classes.
For access to methods of C++ classes (virtual and not) we can use 
extern(C++) interface.

//С++

class CPPTest1
{
     int a;
     int b;
   public:
     virtual int boom();
     int fun();
     static int gun();
     CPPTest1(int);
     virtual ~CPPTest1();
     int&amp;amp; operator[](size_t);
};

class CPPTest2: public CPPTest1
{
     int boom();
};

//D
extern(C++)interface CPPTest1
{
     int boom();
     static int gun();
     final int fun();
}

extern(C++)interface CPPTest2: CPPTest1
{
     //int boom();
}



As a rule, non-static fields are not public in C++ classes and is 
not part of interface. Thus the most of C++ classes can be bound 
without any glue c++ code.
However D dont support C++ overloaded operators and constructors. 
Yes, we cannot make mapping C++ operators to D operators and C++ 
constructors to D constructors). Nonetheless С++ operators and 
constructors are the simple C++ functions or methods with special 
mangling&lt;/pre&gt;</description>
    <dc:creator>Igor Stepanov</dc:creator>
    <dc:date>2013-05-18T22:23:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117879">
    <title>Request d.vim testing</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117879</link>
    <description>&lt;pre&gt;Hello Vim users,

Sadly I don't have a good set of unittests for highlighting. I've 
made some changes and think that it will be good to have them 
part of vim 7.4

I'm requesting that you check that the new file has not butchered 
highlighting for you.

https://github.com/JesseKPhillips/d.vim

* ASM blocks highlight comments
* in/out contracts no longer highlighted as storage class
* If a module name is the same as a keyword it will not be 
highlighted on module declaration or import.
* scope highlights as a statement, as a storage class in 
parameter list
* pragma will highlight known commands (lib,msg)

&lt;/pre&gt;</description>
    <dc:creator>Jesse Phillips</dc:creator>
    <dc:date>2013-05-18T18:12:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117877">
    <title>LDC:  Constant Folding Across Nested Functions?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117877</link>
    <description>&lt;pre&gt;Background:  This came from an attempt to get rid of delegate 
indirection in parallel foreach loops on LDC.  LDC can inline 
delegates that always point to the same code.  This means that it 
can inline opApply delegates after inlining opApply itself and 
effectively constant folding the delegate.

Simplified case without unnecessarily complex context:

// Assume this function does NOT get inlined.
// In my real use case it's doing something
// much more complicated and in fact does not
// get inlined.
void runDelegate(scope void delegate() dg) {
     dg();
}

// Assume this function gets inlined into main().
uint divSum(uint divisor) {
     uint result = 0;

     // If divisor gets const folded and is a power of 2 then
     // the compiler can optimize the division to a shift.
     void doComputation() {
         foreach(i; 0U..1_000_000U) {
             result += i / divisor;
         }
     }

     runDelegate(&amp;amp;doComputation);
}

void main() {
     // divSum gets inlined, to here, but doComputation()
   &lt;/pre&gt;</description>
    <dc:creator>dsimcha</dc:creator>
    <dc:date>2013-05-18T17:39:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117876">
    <title>QtD fails to build on Arch Linux</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117876</link>
    <description>&lt;pre&gt;I'm on 64-bit, so I've used the 64-bit patch [1] on bitbucket to 
get the compile started. I get a lot of these errors:

[  3%] Building CXX object 
CMakeFiles/cpp_core.dir/cpp/qt_core/QAbstractItemModel_shell.cpp.o
/home/otto/sandbox/qtd/build_dir/build/cpp/qt_core/QAbstractItemModel_shell.cpp: 
In member function ‘virtual QModelIndex 
QAbstractItemModel_QtDShell::buddy(const QModelIndex&amp;amp;) const’:
/home/otto/sandbox/qtd/build_dir/build/cpp/qt_core/QAbstractItemModel_shell.cpp:83:141: 
error: taking address of temporary [-fpermissive]
 
qtd_QAbstractItemModel_buddy_QModelIndex_const_dispatch(QObjectLink::getLink(this)-&amp;gt;dId, 
&amp;amp;__d_return_value, &amp;amp;qtd_from_QModelIndex(index0));

I'm using gcc 4.8 if that makes a difference.

I've noticed that the original developers have more or less 
abandoned it (a patch for finding 64-bit dmd sits in the issue 
tracker gathering dust), but it seems to be the only Qt binding 
out there. I've noticed on the D forums that the developers have 
possibly lost interest [2]&lt;/pre&gt;</description>
    <dc:creator>Tyler Jameson Little</dc:creator>
    <dc:date>2013-05-18T17:24:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117867">
    <title>Automatic Follower</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117867</link>
    <description>&lt;pre&gt;Some of you maybe remember the idea of the roles of variables:

http://en.wikibooks.org/wiki/A-level_Computing/AQA/Problem_Solving,_Programming,_Data_Representation_and_Practical_Exercise/Fundamentals_of_Programming/The_Role_of_Variables

http://www.cs.joensuu.fi/~saja/var_roles/role_list.html

The idea is that in a program many variables have roles that can 
be classified in few categories. Modern languages often offer 
ways to express explicitly some of such roles, this makes the 
code more readable and sometimes less bug prone.

One of the roles that isn't built-in in D is the Follower, that 
is variables that get their value by following another data 
entity. They are "used to keep check of a previous value of a 
variable, so that a new value can be compared."

This is a basic implementation of a Follower in D (based on 
std.typecons.Nullable), with an usage example on doubly linked 
lists:


struct WithFollower(T, size_t N) {
     private T[N] _items;

     this(T value) {
         _items[0] = value;
  &lt;/pre&gt;</description>
    <dc:creator>bearophile</dc:creator>
    <dc:date>2013-05-18T14:35:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117856">
    <title>Are people using textmate for D programming?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117856</link>
    <description>&lt;pre&gt;Hi everyone,

I would like to get an idea how many people are using Textmate as 
editor in Mac OS X. I am keen to improve the current bundle. 
Especially the syntax highlighting seems to be stuck somewhere in 
D1 or so... also, it'd be great to have some command to run 
unittests and code-coverage...

I can just proceed and suggest improvements (the bundle is on 
github), but learning about other people using it would increase 
my motivation :-)

Stephan

&lt;/pre&gt;</description>
    <dc:creator>Stephan Schiffels</dc:creator>
    <dc:date>2013-05-18T11:41:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117854">
    <title>DSoC + Kickstarter?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117854</link>
    <description>&lt;pre&gt;As you probably know, the application of D to GSoC 2013 has been 
rejected.
There was an idea about running the program nonetheless, minus 
the funding:
http://forum.dlang.org/post/mailman.613.1365489754.4724.digitalmars-d-announce&amp;lt; at &amp;gt;puremagic.com

Can't we use Kickstarter to fund it?

&lt;/pre&gt;</description>
    <dc:creator>Mr. Anonymous</dc:creator>
    <dc:date>2013-05-18T08:33:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117848">
    <title>Should AliasThis allow implicit conversion to the subtype AliasThisaliases to?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117848</link>
    <description>&lt;pre&gt;I found out about AliasThis on the IRC, and it's pretty neat. 
I've got a suggestion for it however: Assigning a value to a 
class/struct which has aliased a member to this would forward the 
assignment to that member.

For instance:

----
struct IntPair {
private int _pair;
int left()  { return _pair[0]; }
int right() { return _pair[1]; }
}

IntPair a = [1, 2]; // _pair = [1, 2]
IntPair b;
b.left(); //0
b = [3, 4];
b.left(); //3
----

Thoughts? I think it'd be very useful for defining types that 
look and act like built in primitives, but can have arbitrary 
methods and operator overloads attached to them.

Thanks to &amp;lt;jA_cOp&amp;gt; for bringing up AliasThis in IRC :-)

&lt;/pre&gt;</description>
    <dc:creator>Dylan Knutson</dc:creator>
    <dc:date>2013-05-18T07:43:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117827">
    <title>Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117827</link>
    <description>&lt;pre&gt;
Would they? I'm thinking the process would be:

struct S
{
    int x;
    int y = void;

    this()  // hypothetical
    {
        // x would already be initialized to int.init here
        assert(x == int.init);

        // y is left uninitialized here
    }
}

Maybe that's already clear. But why is .init actually such a big
problem? If it becomes arbitrarily expensive to call .init of a
struct, well it's because it has to be - if the user really provided
an expensive default ctor. But it's entirely the user's
responsibility. So then .init can even throw, but throwing exceptions
isn't a big deal. Is there some other problem?

A custom default ctor in a struct is one of the most asked for
features. Just yesterday we spent several hours explaining to a C++
user why a default ctor doesn't work, and what .init is for. The whole
conversation could have been avoided if D had support for custom
default ctors for structs. This topic comes up very often in IRC and
the forums.

&lt;/pre&gt;</description>
    <dc:creator>Andrej Mitrovic</dc:creator>
    <dc:date>2013-05-17T21:34:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117763">
    <title>primitive value overflow</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117763</link>
    <description>&lt;pre&gt;Hello everyone.

Today I ran into a interesting issue. I wrote

   auto offset = text1.length - text2.length;

and in case text2 was longer then text1 I got something around 4294967291.

So I opened an issue:
http://d.puremagic.com/issues/show_bug.cgi?id=10093

I know that there is a perfectly valid reason for this behavior, and 
that this behavior is not undefined, but it is unexpected, especially 
because unsigned is never mentioned in the code. One solution that comes 
to mind is changing length to signed, but that makes no sense because 
length is never negative.

After some thinking a though came that maybe such value overflow should 
be treated the same way as array overflow and checked by druntime with 
optional disabling in production code (like array bound checks)?

I think it would be very helpful to get an error for such mistake (that 
could very easily happen by accident), and on the other hand it can be 
disabled (like all other checks).

&lt;/pre&gt;</description>
    <dc:creator>luka8088</dc:creator>
    <dc:date>2013-05-16T20:24:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117746">
    <title>Investigation: downsides of being generic and correct</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117746</link>
    <description>&lt;pre&gt;Want to bring into discussion people that are not on Google+. 
Samuel recently has posted there some simple experiments with 
bioinformatics and bad performance of Phobos-based snippet has 
surprised me.

I did explore issue a bit and reported results in a blog post 
(snippets are really small and simple) : 
http://dicebot.blogspot.com/2013/05/short-performance-tuning-story.html

One open question remains though - can D/Phobos do better here? 
Can some changes be done to Phobos functions in question to 
improve performance or creating bioinformatics-specialized 
library is only practical solution?


&lt;/pre&gt;</description>
    <dc:creator>Dicebot</dc:creator>
    <dc:date>2013-05-16T10:35:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117721">
    <title>New feature proposal: "initialization scope"</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117721</link>
    <description>&lt;pre&gt;I'd like to make it easier to initialize function local 
immutable/const data. Here's the type of problem I'd like to 
alleviate:

const string[100] int__str;
const int[string] str__int;

for (int i = 0; i &amp;lt; 100; ++i)
{
     auto str = to!string(i);
     int__str[i] = str; // ERROR: Can't modify const
     str__int[str] = i; // ERROR: Can't modify const
}

In short, I want to initialize two different const variables at 
once (in the same loop or other block). If I needed to initialize 
only one const variable, I could use a lambda:

const string[100] int__str = {
     string[100] tmp;
     // ... init tmp ...
     return tmp;
}();

...But I can't see any easy solution for initializing two or more 
const variables at the same time.

Here's my proposal: "initialization scope". You'd use it like 
this:

initialization {
     const string[100] int__str;
     const int[string] str__int;

     for (int i = 0; i &amp;lt; 100; ++i)
     {
         auto str = to!string(i);
         int__str[i] = str; // OK
         str__int&lt;/pre&gt;</description>
    <dc:creator>TommiT</dc:creator>
    <dc:date>2013-05-16T07:53:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117718">
    <title>(X)HTML/XML in DDoc</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117718</link>
    <description>&lt;pre&gt;Good evening, all,

I imagine that this is a sensitive topic, so I'll do my best not 
to flame bait and I hope that readers will assume that I mean the 
best if I don't word things very diplomatically:

I think that the DDoc spec does an excellent job in creating a 
common-sense, low-burdensome way to document source code in-line. 
I think its rules are largely clear and unambiguous. 
Unfortunately, I'm finding that the clarity breaks down once 
macros are introduced.

What sticks out for me is the spec's aversion to XHTML, clearly 
stated in "D's goals for embedded documentation" (number 4) and 
under the bit for Embedded HTML, which discourages HTML in favour 
of macros.

I want to understand why DDoc prefers macros to some XML-based 
markup. I've observed the following things about working with 
DDoc:
1) The DLangSpec is written almost entirely in macros. Most of 
the macros defined for the DLangSpec simply rewrite HTML tags 
into a macro. It seems that the macros copy the functionality of 
the HTML tags &lt;/pre&gt;</description>
    <dc:creator>Borden</dc:creator>
    <dc:date>2013-05-16T06:46:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/117715">
    <title>Embedded D Template generation at compile time</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/117715</link>
    <description>&lt;pre&gt;Hello! I've written a few functions as a way to learn about D 
metaprogramming and CTFE. Maybe they'll be useful to someone else 
too. I'd also love it if I could get some feedback on how the 
code uses various D idioms, and if there's something that could 
be done a better way. The syntax the template language uses is 
the same as embedded ruby, so any Rails/PHP developers will feel 
right at home.

Source + documenting unittests here: 
https://gist.github.com/dymk/bbf6c87e92d5aca3c737

Templates are compiled into a single anonymous D function at 
compile time, and the anon function uses an Appender for its 
internal buffer to maximize speed. It was designed so there is 
minimal overhead at runtime, but I'm sure it could be speed up 
somehow.

An overview of how to use the template functions:

Anything between &amp;lt;% %&amp;gt; is D code
Anything between &amp;lt;%= %&amp;gt; is D code which is evaluated and pushed 
onto the buffer
Anything else is raw text that is pushed onto the buffer

Loops, conditional logic, and declarations al&lt;/pre&gt;</description>
    <dc:creator>Dylan</dc:creator>
    <dc:date>2013-05-16T03:32:36</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.d.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.d.general</link>
  </textinput>
</rdf:RDF>
