On Sunday, 18 September 2016 at 12:16:54 UTC, Andrei Alexandrescu
wrote:
I don't see that as much of a hurdle seeing as any template
written has a few "obvious" types it'll work with. To
encapsulate that if needed:
struct Awesome(A, B, C)
{
private enum ut = is(A == int) && is(B == int)
On Mon, Sep 19, 2016 at 09:02:05AM -0700, H. S. Teoh via Digitalmars-d wrote:
> On Sat, Sep 17, 2016 at 01:22:52PM -0400, Andrei Alexandrescu via
> Digitalmars-d wrote:
> > Recall the discussion a few days ago about unittests inside templates
> > being instantiated with the template. Often that's
On Sat, Sep 17, 2016 at 01:22:52PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
> Recall the discussion a few days ago about unittests inside templates
> being instantiated with the template. Often that's desirable, but
> sometimes not - for example when you want to generate nice ddoc
>
On 9/18/16 8:14 AM, Andrei Alexandrescu wrote:
On 9/18/16 6:00 AM, Jonathan M Davis via Digitalmars-d wrote:
Yes. That's DIP 82:
http://wiki.dlang.org/DIP82
I need to go over it again and then introduce it into the new DIP
process.
But I really think that that's where we should go to fix this
On Sunday, September 18, 2016 20:11:56 Andrei Alexandrescu via Digitalmars-d
wrote:
> Understood. I don't want anyone to get furious later on account of my
> sugarcoating things, so let me say this: I'm likely to oppose such a
> proposal. Walter and I have similar design sensibilities so he's
On 09/18/2016 04:29 PM, Jonathan M Davis via Digitalmars-d wrote:
On Sunday, September 18, 2016 08:14:47 Andrei Alexandrescu via Digitalmars-d
wrote:
On 9/18/16 6:00 AM, Jonathan M Davis via Digitalmars-d wrote:
Yes. That's DIP 82:
http://wiki.dlang.org/DIP82
I need to go over it again and
On Monday, September 19, 2016 01:55:58 Timon Gehr via Digitalmars-d wrote:
> On 18.09.2016 22:10, Jonathan M Davis via Digitalmars-d wrote:
> > In
> > this case, a non-static unittest block would be compiled into each
> > template
> > intsantiation, whereas a static one would be compiled once per
On 18.09.2016 22:52, Jonathan M Davis via Digitalmars-d wrote:
On Sunday, September 18, 2016 13:10:36 Jonathan M Davis via Digitalmars-d
wrote:
On Sunday, September 18, 2016 08:02:47 Andrei Alexandrescu via Digitalmars-d
wrote:
On 9/17/16 5:23 PM, Andrej Mitrovic wrote:
I think at some point
On 18.09.2016 22:10, Jonathan M Davis via Digitalmars-d wrote:
On Sunday, September 18, 2016 08:02:47 Andrei Alexandrescu via Digitalmars-d
wrote:
> On 9/17/16 5:23 PM, Andrej Mitrovic wrote:
> > I think at some point someone suggested we could implement explicit
> > support for such unittests
On Sunday, September 18, 2016 13:10:36 Jonathan M Davis via Digitalmars-d
wrote:
> On Sunday, September 18, 2016 08:02:47 Andrei Alexandrescu via Digitalmars-d
> wrote:
> > On 9/17/16 5:23 PM, Andrej Mitrovic wrote:
> > > I think at some point someone suggested we could implement explicit
> >
> >
On Sunday, September 18, 2016 08:14:47 Andrei Alexandrescu via Digitalmars-d
wrote:
> On 9/18/16 6:00 AM, Jonathan M Davis via Digitalmars-d wrote:
> > Yes. That's DIP 82:
> >
> > http://wiki.dlang.org/DIP82
> >
> > I need to go over it again and then introduce it into the new DIP process.
> >
On Sunday, September 18, 2016 08:02:47 Andrei Alexandrescu via Digitalmars-d
wrote:
> On 9/17/16 5:23 PM, Andrej Mitrovic wrote:
> > I think at some point someone suggested we could implement explicit
> > support for such unittests via `static unittest`:
> That suggests the unittest shall be
On Sunday, 18 September 2016 at 12:02:47 UTC, Andrei Alexandrescu
wrote:
That suggests the unittest shall be evaluated during
compilation. -- Andrei
Nah, static is already quite overloaded and needs context to
understand what it does. For example module constructors.
Anyway compiler
On 09/18/2016 09:01 AM, John Colvin wrote:
What would be really good would be to have a way to make ddoc associate
a unittest with a particular symbol, regardless of location.
Though there are many ways in which we could be better, I really think
we're good.
See e.g.
On Sunday, 18 September 2016 at 12:02:47 UTC, Andrei Alexandrescu
wrote:
On 9/17/16 5:23 PM, Andrej Mitrovic wrote:
I think at some point someone suggested we could implement
explicit
support for such unittests via `static unittest`:
That suggests the unittest shall be evaluated during
On 9/18/16 6:23 AM, Nick Treleaven wrote:
Besides the other comments, we still have to instantiate Awesome!int
somewhere for the tests to run, which could be forgotten or improperly
done, failing silently. (Also int is arbitrary, unhelpful for the
uninitiated).
I don't see that as much of a
On 9/18/16 6:00 AM, Jonathan M Davis via Digitalmars-d wrote:
Yes. That's DIP 82:
http://wiki.dlang.org/DIP82
I need to go over it again and then introduce it into the new DIP process.
But I really think that that's where we should go to fix this problem.
Just a thought: things that we can't
On 9/17/16 5:23 PM, Andrej Mitrovic wrote:
I think at some point someone suggested we could implement explicit
support for such unittests via `static unittest`:
That suggests the unittest shall be evaluated during compilation. -- Andrei
On Sunday, 18 September 2016 at 11:10:22 UTC, ZombineDev wrote:
On Saturday, 17 September 2016 at 17:22:52 UTC, Andrei
Alexandrescu wrote:
[...]
This solution is used extensively by ndslice [1] and I agree
that it's quite flexible.
[1]:
On Saturday, 17 September 2016 at 17:22:52 UTC, Andrei
Alexandrescu wrote:
Recall the discussion a few days ago about unittests inside
templates being instantiated with the template. Often that's
desirable, but sometimes not - for example when you want to
generate nice ddoc unittests and avoid
On Saturday, 17 September 2016 at 17:22:52 UTC, Andrei
Alexandrescu wrote:
///
static if (is(T == int)) unittest
{
Awesome awesome;
awesome.awesome;
}
}
The unittest documentation is nicely generated. The unittest
code itself is only generated for one
On Saturday, September 17, 2016 21:23:58 Andrej Mitrovic via Digitalmars-d
wrote:
> On Saturday, 17 September 2016 at 17:22:52 UTC, Andrei
>
> Alexandrescu wrote:
> > The unittest documentation is nicely generated. The unittest
> > code itself is only generated for one instantiation.
>
> I had a
On Saturday, 17 September 2016 at 17:22:52 UTC, Andrei
Alexandrescu wrote:
The unittest documentation is nicely generated. The unittest
code itself is only generated for one instantiation.
I had a similar thought, but I didn't really like verbosity of
the static if.
I think at some point
Recall the discussion a few days ago about unittests inside templates
being instantiated with the template. Often that's desirable, but
sometimes not - for example when you want to generate nice ddoc
unittests and avoid bloating. For those cases, here's a simple solution
that I don't think has
24 matches
Mail list logo
