See more at the announce forum.
Walter dropped this thing on the forum: https://forum.dlang.org/thread/s79ib1$1122$1@digitalmars.com
You can see some of my more detailed thoughts in the thread, but basically, I do think there's some potential here, but I also expect it is going to be a bigger time investment (and probably smaller real world impact) than Walter seems to have planned. But if it can pull out bindings in as quick time as compiling pre-translated D things and maybe even simplify the build of including other C libraries, there can be value there.
Just don't expect that value to mature too soon.
Also on the newsgroup, Andrei Alexandrescu has been rethinking some of Phobos' implementation. I agree with him for the most part: we should kill these special cases that bloat up the library. Simplifying that will probably lead to better compile times and dmd memory use and later, more consistency in the language.
He's been using Walter's newish (~7 months ago added) alias assign thing to see about simplifying Phobos implementations too. It is finding qualified success, though the alias assign thing is also showing some problems in consistency with static if and such. These may be workable and if not, at least worked around, so it isn't necessarily a dealbreaker, and the nicer implementations, while not yielding huge changes, may justify keeping the feature anyway.
So that's all ok. But on the other hand, Andrei has been unhappy with D's string for a while. (And he blames - with personal insight - string for adding other things to the language like immutable. Funny how much of c++ was added to support std::string and much of D traces back to it too. Strings are a whole string of fun. He seems to kinda regret this but I'm actually fairly happy with how immutable turned out myself.) He tried to fix it before with the autodecoding feature, which is now fairly universally agreed to have been a mistake, so then the next concept was the RCStr - reference counted string, which he talked about at dconf a few years back, but hit some serious problems in making the implementation work - including transitive const getting in the way of that reference count if my memory serves.
Now, he's thinking about a library string type again. Not a lot of details yet, but I know he's still keen on reference counting and would like to have a small-string optimization, in addition to avoiding the autodecoding problem by having it provide various accessors like byCodePoint and byCodeUnit rather than any kind of direct automatic rangeness.
I don't think this is a bad idea. In fact, there's a lot I like about it... but I'm also not convinced it is a good idea. I personally find D's strings to be a big win - they're lightweight, they're convenient, and they're compatible. Yes, I even like wstring, and to a lesser extent, dstring is sometimes useful.
Phobos' string handling is not great. But D, the language, does a great job if you ask me (though pity const(char)[] wasn't as convenient to write as string.. many functions require the immutable reference when they probably don't actually benefit from it just because const(char)[] is more awkward to write blargh) and it is very flexible between managing slices yourself and UFCS extensions. Those byCodeUnit things are already there, for example. You can malloc a string and if that @live and dip1000 and whatnot stuff actually delivers, you could offer scope (possibly const) references as a slice to use in other places while keeping some kind of COW or ref count or whatnot scheme for owners.
If all that comes together, I think I'd welcome a library string type as a complement to to the language's existing capabilities. That'd be pretty useful.
But then the question would be: how many string types do we have? Why is "string literal" not of type String if that's what all the libraries are using? Will that require people to write use_string(String("literal"))? That seems silly. Or will we get (explicit) implicit construction of params and return values oh my that would bring me some joy! I want those anyway!
What about existing code using string? Well, the scope borrowed reference can still pass to them, or you can idup. I don't think that's actually that big of a deal. But it is likely to be a source of friction.
So while I like a lot of the ideas, I do worry they might come at the expense of what we already have working well - don't break my strings and wstrings!
I'm thus an undecided voter on this issue (as if our votes matter lol).
I heard through reliable sources that gdc and ldc will both be addressing the druntime-as-dll-on-Windows problem shortly, generating the same kind of indirections that MSVC does and adding "export all" switches.
ldc's fix will probably not fix unique typeinfo and full exception merging but it should fix most everything else that is liable to go wrong with d exes loading d dlls thanks to reducing code duplucation. gdc's solution also uses mingw's relocation fixup code to likely fix even more.
Pretty exciting stuff, these issues have been open for a very, very long time. I expect it will be a few more months until they work out into a beta release though.
There's also an improved string interpolating dip in the works so stay tuned for that. My inside scoop on it brings me some joy, it hits the points I wanted (including one I thought was practically impossible to get others to agree to!).
I'm going to save most my writing on this for next week, but I did another minigui thing I've been pondering for a while - some visual theme override capability in user code for the custom_widgets version. You can change the font and such now for the interface on Linux. I did this with the curiously-recurring template pattern again, this time to make an extensible visitor. I'm not quite done with this and wrote enough this week anyway, so I'll go into more details next week. I may also release the event stuff from last week, but also pondering extending that a wee bit more with state broadcasts to children and writing up a conventions document on receiving commands from children too. The idea is to support like fully decoupled scroll areas as an example. But we'll see, I'm undecided right now.
Simultaneously, I also received a request to add more tui components to terminal.d. I resisted this before since I don't really like most tuis and it seemed like so much duplication with minigui, but I do have the getline function for input processing and a scrollable area class for output processing so if I just combined them, I'd have something kinda similar to the ncurses window concept. Just have to take care of clipping and maybe auto scrolling. Good chance I'll release that for next week as well.
Walter dropped a basic C compiler in a DMD pr this week, Andrei on evolving Phobos, and meanwhile I've been working on more user interface library code.