Re: DIP Draft Review: ref const(T) should receive r-values
On Monday, 2 April 2018 at 05:09:29 UTC, Mike Parker wrote: On Monday, 2 April 2018 at 05:06:21 UTC, Mike Parker wrote: Please keep feedback on the DIP in the PR thread. Thanks in advance to all who participate. https://github.com/dlang/DIPs/pull/109 Sorry everyone. Got my links mixed up. This is the rvalue references DIP: https://github.com/dlang/DIPs/pull/111
Re: DIP Draft Review: Hooking D's struct move semantics
On Monday, 2 April 2018 at 05:07:25 UTC, Mike Parker wrote: On Monday, 2 April 2018 at 04:34:03 UTC, Mike Parker wrote: Please keep feedback on the DIP in the PR thread. Thanks in advance to all who participate. https://github.com/dlang/DIPs/pull/111 Sorry everyone. Got my links mixed up. This is the opMove DIP: https://github.com/dlang/DIPs/pull/109
DIP Draft Review: ref const(T) should receive r-values
This DIP is a candidate to become DIP 1014. There's already been some discussion about this in the forums and some feedback on the PR, but more Draft Review feedback is needed. The intent of the Draft Review is primarily to find obvious flaws with the DIP, e.g. structural faults, uncovered bases, lack of clarity, etc.. At this stage of the process, the end goal is to shape the DIP into a strong draft for in-depth review. Feedback at this stage will not be included in the review summary, so any theoretical discussions or in-depth examination of minutiae are best saved for the community review. Please keep feedback on the DIP in the PR thread. Thanks in advance to all who participate.
DIP Draft Review: Hooking D's struct move semantics
This DIP is a candidate to become DIP 1014. There has been light feedback already, but there's room for more. Everyone is invited to participate. The intent of the Draft Review is primarily to find obvious flaws with DIP, e.g. structural faults, uncovered bases, lack of clarity, etc.. At this stage of the process, the end goal is to shape the DIP into a strong draft for in-depth review. Feedback at this stage will not be included in the review summary, so any theoretical discussions or in-depth examination of minutiae are best saved for the community review. Please keep feedback on the DIP in the PR thread. Thanks in advance to all who participate.
Re: std.variant Is Everything Cool About D
On Saturday, 31 March 2018 at 17:36:30 UTC, Pjotr Prins wrote: Great blog. Thanks. Thank you, glad you liked it.
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On 2018-03-30 08:53, Dmitry Olshansky wrote: With the frame of mind prevalent in our Industry I really want to have compiler includibg codegen as a bunch of library components. Then there is no problem innovating while people argue over things “allowed” for a compiler, or a linker, or a build tool. None of these actually have to be apps talking via files. If I look closely every program I see is a graph database, with nodes sometimes being code, types, sometimes data, other meta-data such as ABI attributes or conditional compilation flags, documentation, external tools, specs and databases are also part of this. Code that produces code is also part of such graph, and CTFE/macroses would just be finer grained approach. Why process graphs piece-wise in a frentic dance of command-line tools that try to fit all to a tree of files (multiple ones, in many location, and part in some CMS) and then have editors/IDEs integrate? Was easier I believe + inertia, easy != simple though. I completely agree. I was quite surprised when I started to use libclang and the only way to pass options to the library (which are usually command line flags) was to pass it as an array of command line options. This is the C API, the C++ API is more advanced. -- /Jacob Carlborg
