On Sunday, 14 July 2013 at 05:30:57 UTC, lomereiter wrote:
On Sunday, 14 July 2013 at 05:04:37 UTC, JS wrote:
and while I'm at it I need to conditionally constrain types.
interface A(T) where(!isBasicType!T, (T : B));
which is suppose to require T to inherit from B if T is not
basic type.
i
On Sunday, 14 July 2013 at 05:28:08 UTC, lomereiter wrote:
This should work:
template conditionallyInherit(bool inherit, T) {
static if (inherit)
alias T conditionallyInherit;
else
interface conditionallyInherit {}
}
Thanks, I tried something similar but it didn't work
On Sunday, 14 July 2013 at 05:04:37 UTC, JS wrote:
and while I'm at it I need to conditionally constrain types.
interface A(T) where(!isBasicType!T, (T : B));
which is suppose to require T to inherit from B if T is not
basic type.
interface A(T) if (isBasicType!T || is(T : B))
This should work:
template conditionallyInherit(bool inherit, T) {
static if (inherit)
alias T conditionallyInherit;
else
interface conditionallyInherit {}
}
and while I'm at it I need to conditionally constrain types.
interface A(T) where(!isBasicType!T, (T : B));
which is suppose to require T to inherit from B if T is not basic
type.
I need to conditionally inherit:
interface A(T) : conditionallyInherit!(isBasicType!T, B);
A!(double) will inherit B but A!(mytype) won't.
It would be nice if this is possible:
interface A // : gets inserted by the mixin
{
mixin sometemplate!B; // Is able to make A extend B
}
or
interface A : mixin sometemplate!B
{
// methods get inserted by the template
}
instead of
interface A : B
{
mixin sometemplate!B;
}
which
> Also note that if the pointer in C land is the only reference to the
> class, the garbage collector will destroy the instance when it gets
> around to it.
Yup, I am aware of this. I mentioned that I can guarantee that my
object will outlive the C struct...
> There's a function GC.addRoot[1] in
On 2013-07-13, 20:53, Leandro Motta Barros wrote:
Hey, thanks! This makes sense :-)
Am I now wondering... how safe, portable and future proof would this
be? If some future version of D implements a garbage collector capable
of moving objects around the heap, I could get in trouble, right?
Als
Good. Thanks again!
LMB
On Sat, Jul 13, 2013 at 4:01 PM, Adam D. Ruppe
wrote:
> On Saturday, 13 July 2013 at 18:54:18 UTC, Leandro Motta Barros wrote:
>>
>> If some future version of D implements a garbage collector capable of
>> moving objects around the heap, I could get in trouble, right?
>
>
On Saturday, 13 July 2013 at 18:54:18 UTC, Leandro Motta Barros
wrote:
If some future version of D implements a garbage collector
capable of moving objects around the heap, I could get in
trouble, right?
Maybe, but I don't think D would do that because a lot of D code
uses C libraries. At the
Hey, thanks! This makes sense :-)
Am I now wondering... how safe, portable and future proof would this
be? If some future version of D implements a garbage collector capable
of moving objects around the heap, I could get in trouble, right?
LMB
On Sat, Jul 13, 2013 at 3:35 PM, Adam D. Ruppe
wro
On Saturday, 13 July 2013 at 18:30:24 UTC, Leandro Motta Barros
wrote:
So, is there some way to store a reference to a D class
instance in that 'user_data' field?
Should be ok to cast the reference itself to that type - don't
take the address of it, since that would be the address of a
local,
Hello,
TL;DR: Can I somehow store a reference to a D class instance in a
field of a struct from a C library I am using with my D code?
The long story:
I am writing some D code that uses a C library. This C library
provides an event handling mechanism in which events are represented
by (plain C)
On Sat, Jul 13, 2013 at 05:08:11PM +0200, JS wrote:
> On Saturday, 13 July 2013 at 01:06:09 UTC, H. S. Teoh wrote:
[...]
> >I find this fixation on syntax rather strange. As long as the syntax
> >is not *too* ugly (*cough*C++ templates*cough*) isn't the *semantics*
> >more important? A pretty langu
On Sat, 2013-07-13 at 12:43 +0200, ixid wrote:
> > I think that Python has syntax evidently and demonstrably
> > superior to D. Why not Python?
>
> White spaces with meaning cause hard to find bugs, the Python
> syntax is not appropriate for large projects and this is well
> known. That is not
On Saturday, 13 July 2013 at 01:06:09 UTC, H. S. Teoh wrote:
On Fri, Jul 12, 2013 at 05:51:21PM -0700, Brad Roberts wrote:
On 7/12/13 1:46 PM, ixid wrote:
[...]
>It seems a pity that D is achieving such power and elegance
>in some
>areas while failing to take on some of the syntactic beauty
>
ixid:
White spaces with meaning cause hard to find bugs, the Python
syntax is not appropriate for large projects and this is well
known.
Well known by who? What's your evidence? My experience says
otherwise :-)
Bye,
bearophile
I think that Python has syntax evidently and demonstrably
superior to D. Why not Python?
White spaces with meaning cause hard to find bugs, the Python
syntax is not appropriate for large projects and this is well
known. That is not the case for the small changes Go has made.
On Saturday, 13 July 2013 at 06:56:46 UTC, Ali Çehreli wrote:
On 07/12/2013 10:34 PM, QAston wrote:> On Saturday, 13 July
2013 at 04:42:58 UTC, QAston wrote:
>> Also, i don't know what's wrong with parens - 2 additional
keystrokes?
>> I didn't see a for loop i a long time - ranges + foreach are
On 07/12/2013 10:34 PM, QAston wrote:> On Saturday, 13 July 2013 at
04:42:58 UTC, QAston wrote:
>> Also, i don't know what's wrong with parens - 2 additional keystrokes?
>> I didn't see a for loop i a long time - ranges + foreach are
>> everywhere. And foreach is 4 chars more to type than for :P.
21 matches
Mail list logo
