The problem is that D does not have any formal semantics for its
informal type system (this, of course, being a tautological statement).
The discovery of any "cool idiom" for disabling "pesky implicit
conversion" is tantamount to engaging the same sorts of hacks
that web programmers do with CSS (C
Maybe I don't understand your problem exactly, but in answer to
what you said here ...
> Because of covariance, this works
> awesome because you always get back the type you are using.
.. If you know in the first place (presumably by static analysis) the type you
are using then you know the ty
Walter Bright wrote:
Norbert Nemec wrote:
Walter Bright wrote:
The trouble with a generator using the caller's stack is that then
the generator cannot recursively call itself (such as if it was
walking a tree). In order to work properly in the general case, a
generator has to allocate all its
Steven Schveighoffer, el 18 de marzo a las 21:34 me escribiste:
> A proposed syntax:
>
> final return this add(V v)
> {
> bool ignored;
> add(v, ignored);
> // no return necessary?
> }
>
> There's probably not a huge need for it, but I just thought I'd put
> the idea out there.
Or you can
Don:
> Not without loss of capability.
So this means "all separately instantiated add() functions with T that the
compiler can automatically cast to uint":
void add(T:ulong)(T x) {
So it's something very different from the template constraint, that just
accepts/refuses to see the template accor
Norbert Nemec wrote:
Walter Bright wrote:
The trouble with a generator using the caller's stack is that then the
generator cannot recursively call itself (such as if it was walking a
tree). In order to work properly in the general case, a generator has
to allocate all its local variables on th
bearophile wrote:
Don:
Do you know why this semantics:
void add(Tulong)(Tulong x) if ( is(Tulong == ulong) )
Is different from this one?
void add(Tulong:ulong)(Tulong x) {
This page says:
http://www.digitalmars.com/d/2.0/templates-revisited.html
T:int,// T must be int type
So it
Walter Bright wrote:
The trouble with a generator using the caller's stack is that then the
generator cannot recursively call itself (such as if it was walking a
tree). In order to work properly in the general case, a generator has to
allocate all its local variables on the heap.
Which concep
Walter Bright wrote:
Norbert Nemec wrote:
Regan Heath wrote:
So, these generators are essentially inline functions?
No. They may be inlined, but this is just an optimization just like
for regular functions. If they are not inlined, these generators are
simply functions with a special calli
Don:
Do you know why this semantics:
> void add(Tulong)(Tulong x) if ( is(Tulong == ulong) )
Is different from this one?
void add(Tulong:ulong)(Tulong x) {
This page says:
http://www.digitalmars.com/d/2.0/templates-revisited.html
T:int,// T must be int type
So it seems the same as th
Lars T. Kyllingstad wrote:
For completeness' sake you should probably also add a 'sudo' in front of
'dpkg'. I forgot that in my post.
Ok.
I've found a pretty cool idiom for disabling pesky implicit conversion.
This is a situation that I've encountered with BigInt; but I think it's
a general problem.
I have an "add integer" operation. Let's call it:
void add( x ), where x is a built-in integral type.
If I define add(long x), ever
Walter Bright wrote:
Lars T. Kyllingstad wrote:
The 32-bit DMD compiler works fine on 64-bit Ubuntu, even though the
.deb file is marked as i386. Try this:
dpkg -i --force-architecture dmd_2.041-0_i386.deb
Note that since the compiler is 32-bit, it only works with 32-bit
libraries. You m
13 matches
Mail list logo
