On Monday, 3 November 2008 at 12:29:16 UTC, Simen Kjaeraas wrote:
On Mon, 03 Nov 2008 12:33:05 +0100, Denis Koroskin
<2kor...@gmail.com> wrote:
On Mon, 03 Nov 2008 04:11:20 +0300, Daniel Ribeiro Maciel
wrote:
Denis Koroskin Wrote:
On Mon, 03 Nov 2008 01:59:56 +0300, Daniel Ribeiro
On Sat, 08 Dec 2018 20:16:09 +, Andrew Pennebaker wrote:
> I think it's lame to have to use magical code like `version(unittest) {}
> else` to guard our main functions, when we run unit tests. Could D go
> ahead and do the right thing, automatically shadowing our main functions
> when the unit
On Saturday, 8 December 2018 at 20:16:09 UTC, Andrew Pennebaker
wrote:
I think it's lame to have to use magical code like
`version(unittest) {} else` to guard our main functions, when
we run unit tests. Could D go ahead and do the right thing,
automatically shadowing our main functions when
I think it's lame to have to use magical code like
`version(unittest) {} else` to guard our main functions, when we
run unit tests. Could D go ahead and do the right thing,
automatically shadowing our main functions when the unit tests
are run?
On Saturday, 16 July 2016 at 20:22:15 UTC, Seb wrote:
On Thursday, 14 July 2016 at 10:13:38 UTC, dom wrote:
On Thursday, 14 July 2016 at 00:33:50 UTC, ethgeh wrote:
On Wednesday, 13 July 2016 at 19:41:53 UTC, dom wrote:
how can i run my unittests for a dynamic library? some weird
conflict is
On Saturday, 8 December 2018 at 16:58:24 UTC, Vladimirs Nordholm
wrote:
Is there a best practice to enabling specific parts of a
library?
For my terminal library, I put it all in a struct. Then the user
gets to choose how to initialize it, and its destructor gets a
chance to cleanup when
Hello.
Pre-rant:
-
I have a library to aid in development for the terminal. This
library has to initialize some things before it can be used, and
I run some code in `shared static this(){...}`. I believe in the
most common case scenario my initializer should be run.
The initializer
On Saturday, 8 December 2018 at 09:57:29 UTC, aliak wrote:
This compiles fine. However, if I change the match template to:
template match(handlers...) {
auto match(alias f)(Holder!f holder) {
return handlers[0](holder);
}
}
Notice the template parameter of the eponymous match
On Saturday, 8 December 2018 at 13:02:00 UTC, Yuxuan Shui wrote:
This surprised me A LOT:
https://d.godbolt.org/z/82a_GZ
So if I call something.map!().array, I get an array of
delegates? That makes no sense to me.
But in your example, "(a) =>" returns "{return tmp;}", which is a
delegate.
This surprised me A LOT:
https://d.godbolt.org/z/82a_GZ
So if I call something.map!().array, I get an array of delegates?
That makes no sense to me.
On Saturday, 8 December 2018 at 03:30:30 UTC, Jonathan M Davis
wrote:
There's one main per program, not per module. Where main lives
depends on how the program was written, but dub encourages
putting it in app.d, because that's what it generates when you
create a new dub project. imports then
Hi, I'm wondering about why this happens in a certain situation
and not another. I have the following code:
struct Holder(alias fun) {
alias T = typeof(fun());
T get() { return fun(); }
alias get this;
}
template match(handlers...) {
auto match(T)(T holder) {
return
12 matches
Mail list logo
