Am 04.08.2012 04:42, schrieb Jonathan M Davis:
On Saturday, August 04, 2012 02:37:07 Stefan Scholl wrote:
bearophilebearophileh...@lycos.com wrote:
Caligo:
When are allocators going to be ready?
Direct experience shows me that once things are in Phobos, it's
not easy to fix their
On Saturday, August 04, 2012 11:25:35 Paulo Pinto wrote:
Where should it be hosted, github?
Probably. That's where we're putting everything else.
- Jonathan M Davis
On 04-08-2012 04:57, Jonathan M Davis wrote:
On Saturday, August 04, 2012 04:44:12 Alex Rønne Petersen wrote:
It's been discussed a time or two that we should have an incubator project
for Phobos where potential Phobos modules go to be used and ironed out
before actually being reviewed for
On 2012-08-02 21:18, Walter Bright wrote:
Another big pile of bug fixes. More contributors than ever!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.075.zip
http://www.digitalmars.com/d/2.0/changelog.html
On Saturday, August 04, 2012 15:09:50 Alex Rønne Petersen wrote:
On 04-08-2012 04:57, Jonathan M Davis wrote:
On Saturday, August 04, 2012 04:44:12 Alex Rønne Petersen wrote:
It's been discussed a time or two that we should have an incubator
project
for Phobos where potential Phobos
On Saturday, 4 August 2012 at 03:07:21 UTC, Era Scarecrow wrote:
Then doesn't it seem like we're missing a potentially important
piece of the puzzle for mixins and templates? very likely my
modified template will include you including the same variable
twice, but if someone gets lazy then it
On Saturday, 4 August 2012 at 03:12:01 UTC, Kapps wrote:
On Saturday, 4 August 2012 at 02:20:45 UTC, Stefan Scholl wrote:
[...]
C# is a terrible language to make a game in.
[...]
-Does not compile to native code, so your game will have
performance issues.
Just use ngen when installing the
It's worth pointing out the obvious, i.e. that as long as 'const'
is physical const instead of logical const (which is always),
invariants and contracts can't be const, because that would
restrict them from calling methods that are logically but not
physically const.
So I think they probably
On Saturday, 4 August 2012 at 06:53:16 UTC, Mehrdad wrote:
It's worth pointing out the obvious, I.e. that as long as
'const' is physical const instead of logical const (which is
always), invariants and contracts can't be const, because that
would restrict them from calling methods that are
On Friday, 3 August 2012 at 02:16:22 UTC, bearophile wrote:
Robert:
im a c++/c# developper and i really want to try D.
I am currently developing a MMORPG, client part is in c++ and
server in c#, i want to know if D language is ok for the
client side ?
Its a simple 2d isometric game using
On Saturday, August 04, 2012 09:06:19 Era Scarecrow wrote:
As mentioned before, doesn't 'const' _only_ apply to the current
(this) object and not anything else? Besides the contracts can't
have lasting side effects that would change logical execution.
How would changing the current object in
On Saturday, August 04, 2012 09:13:48 SomeDude wrote:
Well, normally, with the new STABLE branch, this is going to be a
thing of the past
LOL. No offense, but it's really not going to fix the problem. It'll mitigate
it
somewhat, but it won't fix it. Bug fixes break code all the time
On Saturday, 4 August 2012 at 07:15:50 UTC, Jonathan M Davis
wrote:
The problem is that if the this pointer/reference is const,
then you can't call any member functions which aren't const,
and you can't call any non-const functions on any member
variables, because _they're_ const, because the
On Fri, 2012-08-03 at 18:56 +0200, Alex Rønne Petersen wrote:
On 03-08-2012 18:48, Russel Winder wrote:
[…]
There is no Debian or Mint deb, is this just lack of resources or
decision not to support anything other than Ubuntu?
The .deb will work on Debian, Ubuntu, and Linux Mint. I can
Le 03/08/2012 21:19, Alex Rønne Petersen a écrit :
Hi,
This:
$ cat test.d
class A
{
int i;
invariant()
{
i = 42;
}
}
Currently doesn't compile:
$ dmd test.d
test.d(7): Error: can only initialize const member i inside constructor
(Obviously this example is silly, but it's just meant to
Le 03/08/2012 22:41, Alex Rønne Petersen a écrit :
Further, I had to insert casts that cast away constness in some cases
because the standard library just isn't const-friendly enough. We need
to get our priorities straight.
Why don't you think this is actually the issue ? (I do).
BTW, const
On Saturday, August 04, 2012 10:37:55 deadalnix wrote:
I don't.
Actually, it save from many mistakes. You are always free to cast away
const. This is unsafe, but you are in an invariant and aren't supposed
to do non const operation. At the end, this is fair.
All that would be required to
On Saturday, 4 August 2012 at 03:07:21 UTC, Era Scarecrow wrote:
This can't work in general. What should such a function
return? The fully qualified name, I.e. including packages and
modules? What is if the referred to entity is a nested
function/local variable? What is if it is defined in a
Le 03/08/2012 21:59, Walter Bright a écrit :
On 8/3/2012 6:18 AM, deadalnix wrote:
lexer can have a parameter that tell if it should build a table of
token or
slice the input. The second is important, for instance for an IDE :
lexing will
occur often, and you prefer slicing here because you
Jonathan M Davis , dans le message (digitalmars.D:174191), a écrit :
On Thursday, August 02, 2012 11:08:23 Walter Bright wrote:
The tokens are not kept, correct. But the identifier strings, and the string
literals, are kept, and if they are slices into the input buffer, then
everything I said
On 04-Aug-12 14:02, Christophe Travert wrote:
Jonathan M Davis , dans le message (digitalmars.D:174191), a écrit :
On Thursday, August 02, 2012 11:08:23 Walter Bright wrote:
The tokens are not kept, correct. But the identifier strings, and the string
literals, are kept, and if they are slices
On Saturday, 4 August 2012 at 08:53:20 UTC, David Nadlinger wrote:
How do you determine what the »local level« is? A string
mixin isn't something you can »call«, just a compile-time
constant string, which can be »evaluated« in a completely
different place than it can be constructed. Maybe some
Era Scarecrow , dans le message (digitalmars.D:174206), a écrit :
I would think it does however during verbose output specifying
if an invariant or contract is changing data and that may alter
behavior.
Signatures in some place should be by default const, pure, nothrow. This
is the case
Dmitry Olshansky , dans le message (digitalmars.D:174214), a écrit :
Most likely - since you re-read the same memory twice to do it.
You're probably right, but if you do this right after the token is
generated, the memory should still be near the processor. And the
operation on the first read
On Saturday, 4 August 2012 at 10:08:34 UTC, Era Scarecrow wrote:
---
mixin template BitfieldsOn(alias target, …) if
(isIntegral!(typeof(target))) {
mixin({
string code;
// Generate code using target as identifier.
return code;
}());
}
mixin BitfieldsOn!(foo, …);
I am getting indications that there are a number of very severe
thread-related breakages in 2.060 at least on Debian Unstable using the
debs. Some of my codes that use threads explicitly work fin with 2.059
but are showing a variety of errors with 2.060. I will put a few bug
reports in and then
On 04-Aug-12 14:55, Christophe Travert wrote:
Dmitry Olshansky , dans le message (digitalmars.D:174214), a écrit :
Most likely - since you re-read the same memory twice to do it.
You're probably right, but if you do this right after the token is
generated, the memory should still be near the
On Sat, Aug 4, 2012 at 10:53 AM, David Nadlinger s...@klickverbot.at wrote:
example:
---
mixin template BitfieldsOn(alias target, …) if
(isIntegral!(typeof(target))) {
mixin({
string code;
// Generate code using target as identifier.
return code;
}());
}
On Sat, Aug 4, 2012 at 1:23 PM, David Nadlinger s...@klickverbot.at wrote:
On Saturday, 4 August 2012 at 10:08:34 UTC, Era Scarecrow wrote:
---
mixin template BitfieldsOn(alias target, …) if
(isIntegral!(typeof(target))) {
mixin({
string code;
// Generate code using target
On Saturday, August 04, 2012 15:32:22 Dmitry Olshansky wrote:
I see it as a compile-time policy, that will fit nicely and solve both
issues. Just provide a templates with a few hooks, and add a Noop policy
that does nothing.
It's starting to look like figuring out what should and shouldn't be
Andrei Alexandrescu:
(*) Ada has many features missing in D that make its programs
significantly safer than D programs, like:
- built-in ranged integers;
- user-defined array indexes;
- clean syntax to stack-allocate matrices of runtime-defined
sizes;
- pointer kinds with different
On 08/04/2012 01:35 PM, Philippe Sigaud wrote:
On Sat, Aug 4, 2012 at 10:53 AM, David Nadlingers...@klickverbot.at wrote:
example:
---
mixin template BitfieldsOn(alias target,…) if
(isIntegral!(typeof(target))) {
mixin({
string code;
// Generate code using target as
On 04-08-2012 10:35, Russel Winder wrote:
On Fri, 2012-08-03 at 18:56 +0200, Alex Rønne Petersen wrote:
On 03-08-2012 18:48, Russel Winder wrote:
[…]
There is no Debian or Mint deb, is this just lack of resources or
decision not to support anything other than Ubuntu?
The .deb will work on
On Saturday, 4 August 2012 at 11:58:09 UTC, Jonathan M Davis
wrote:
On Saturday, August 04, 2012 15:32:22 Dmitry Olshansky wrote:
I see it as a compile-time policy, that will fit nicely and
solve both
issues. Just provide a templates with a few hooks, and add a
Noop policy
that does nothing.
On 04-08-2012 13:32, Russel Winder wrote:
I am getting indications that there are a number of very severe
thread-related breakages in 2.060 at least on Debian Unstable using the
debs. Some of my codes that use threads explicitly work fin with 2.059
but are showing a variety of errors with
On 04-Aug-12 15:48, Jonathan M Davis wrote:
On Saturday, August 04, 2012 15:32:22 Dmitry Olshansky wrote:
I see it as a compile-time policy, that will fit nicely and solve both
issues. Just provide a templates with a few hooks, and add a Noop policy
that does nothing.
It's starting to look
On Sat, 2012-08-04 at 15:24 +0200, Alex Rønne Petersen wrote:
[…]
Can you give some more details of how things are breaking?
A *lot* of threading and GC related patches were applied in 2.060, and
it's certainly not impossible that some of them have broken something,
but I need more details
On Sat, 2012-08-04 at 15:11 +0200, Alex Rønne Petersen wrote:
[…]
Yeah, that's because DMD has -m32 to cross-compile for 32-bit. It's a
bit silly that it's not optional.
Not a big deal though, just a bit of a surprise.
Kudos to Jordi Sayol the Ubuntu deb works fine on Debian Unstable.
Mayhap
On 8/4/12 4:45 AM, Jonathan M Davis wrote:
D needs to work well with const, but one of the goals is also to make it so
that it's not required if you don't want to or can't use it. Forcing
invariants to be const goes against this. But that decision was probably made
before the recent decisions on
On 04-08-2012 15:52, Russel Winder wrote:
On Sat, 2012-08-04 at 15:11 +0200, Alex Rønne Petersen wrote:
[…]
Yeah, that's because DMD has -m32 to cross-compile for 32-bit. It's a
bit silly that it's not optional.
Not a big deal though, just a bit of a surprise.
Kudos to Jordi Sayol the Ubuntu
On 8/4/12 8:25 AM, bearophile wrote:
Andrei Alexandrescu:
(*) Ada has many features missing in D that make its programs
significantly safer than D programs, like:
- built-in ranged integers;
- user-defined array indexes;
- clean syntax to stack-allocate matrices of runtime-defined sizes;
-
Andrei Alexandrescu:
I wasn't referring the clarity of explanation, just that I
think this sort of righteous pontification - cheap to produce,
yet implying vast insight - doesn't add any value to the
exchange.
I agree that my answers were a little OT to the main discussion
of this thread.
Dwarf2 exceptions work in clang+gcc on win32. It would be SOME
exception handling (and quite interesting, I'd say).
On 2012-08-04 17:20, Kagamin wrote:
Dwarf2 exceptions work in clang+gcc on win32. It would be SOME exception
handling (and quite interesting, I'd say).
This post recently appeared on the Clang mailing list:
Hi,
I have just been made aware that GCC 4.7.2 and later will use SEH by
default on
On Sat, Aug 4, 2012 at 3:04 PM, Timon Gehr timon.g...@gmx.ch wrote:
This should be
explained somewhere, as it's a tool anyone using templates to do
metaprogramming should be aware of.
http://d.puremagic.com/issues/show_bug.cgi?id=7653
Yes. There is a workaround, but we lose the elegance of
So the existing -property in the compiler as absolutely
worthless. It is semantically wrong.
@property void function() func() {
return { assert(0, success); };
}
void main() {
func(); // should assert 0 success, doesn't
auto dele = func;
dele(); // should assert
I should add: if a function is not marked @property, it should
not change at all: it should be callable with and without parens,
including sometimes referring to the wrong thing, exactly like it
is now.
I come to fix code, not to break it. Rewriting references to
@property function names
Le 04/08/2012 19:13, Adam D. Ruppe a écrit :
So the existing -property in the compiler as absolutely worthless. It is
semantically wrong.
@property void function() func() {
return { assert(0, success); };
}
void main() {
func(); // should assert 0 success, doesn't
auto dele = func;
dele(); //
On Saturday, 4 August 2012 at 17:35:03 UTC, deadalnix wrote:
Except for that thing, 100% agreed.
I think you're right about that too...
On 8/4/2012 6:50 AM, Russel Winder wrote:
I put up issue 8505 as an easy one, well easy to report anyway. I
marked it blocking but it is also a regression. I am not sure how to
treat regression in terms of a total ordering with blocking and
critical. Hopefully the fix is easy and 2.061 can come
I think I've cracked the getters...
I opened expression.c in DMD and surfed to line 2940 or so. Looks
like this:
{
error(forward reference to %s, toChars());
return new ErrorExp();
}
return new VarExp(loc, f, hasOverloads);
The function is
On 2012-08-04 19:13, Adam D. Ruppe wrote:
This would also fix things like
func += 10;
if func returned a ref int.
===
@property ref int func() {
static int a;
return a;
}
void main() {
// all of these should work; func should look just like an int
to the outside
On 2012-08-04 21:08, Jacob Carlborg wrote:
I think that you should always be able to replace a variable with a
property. The other way around I'm not so sure. The problem is with
methods in classes. Since a method will be virtual by default you can't
just replace a property with a variable.
On Saturday, August 04, 2012 21:11:47 Jacob Carlborg wrote:
On 2012-08-04 21:08, Jacob Carlborg wrote:
I think that you should always be able to replace a variable with a
property. The other way around I'm not so sure. The problem is with
methods in classes. Since a method will be virtual
On Saturday, 4 August 2012 at 19:08:58 UTC, Jacob Carlborg wrote:
I don't think that's correct behavior. I think the correct
behavior would be to have a property rewrite, something like
this:
Yes, I agree in general, but if a getter returns a ref, you should
be able to write to it... I think
I just downloaded a copy of D-IDE and it downloaded a fresh copy
of 2.060 and I tried to compile a brand new hello world. Anyone
explain what I might have incorrectly setup?
main.d:
import std.stdio, std.cstream;
void main(string[] args){
writeln(Hello World!);
din.getc();
}
On Saturday, 4 August 2012 at 19:35:35 UTC, Hans Uhlig wrote:
I just downloaded a copy of D-IDE and it downloaded a fresh
copy of 2.060 and I tried to compile a brand new hello world.
Anyone explain what I might have incorrectly setup?
You probably still have stale .di files from your last
On Saturday, 4 August 2012 at 11:23:07 UTC, David Nadlinger wrote:
I'm not sure what you mean with »[…] the only acceptable
input is a string; Since strings won't hold the type
information...« – the input to BitfieldsOn is _not_ a
string, it is an alias. The trick is that you can refer to it
Jonathan M Davis , dans le message (digitalmars.D:174223), a écrit :
On Saturday, August 04, 2012 15:32:22 Dmitry Olshansky wrote:
I see it as a compile-time policy, that will fit nicely and solve both
issues. Just provide a templates with a few hooks, and add a Noop policy
that does nothing.
On Saturday, 4 August 2012 at 19:08:58 UTC, Jacob Carlborg wrote:
foo += 10;
Is rewritten as:
auto __tmp = foo;
foo = __tmp + 10;
I did this and now I think this thing is almost done
===
int a;
@property int funcprop() {
writeln(calling the getter and getting , a);
return
At present (though it didn't used to work this way until about 4 months ago -
the change is in 2.060), a number of std.traits templates - including
isSomeString - evaluate to false for enums. So,
enum E : string { a = hello }
static assert(isSomeString!(E.a));
will fail. This is in spite of
On Saturday, August 04, 2012 14:09:29 Jonathan M Davis wrote:
I think that the change to std.traits was a big mistake and will probably
file it as a regression, but I thought that I should get other people's
thoughts on this.
http://d.puremagic.com/issues/show_bug.cgi?id=8508
- Jonathan m
OK, I just compiled one of my work apps with the hacked up dmd.
It caught me using properties as functions in a few places, which
I had to fix by removing the parenthesis from some places, and
the @property from a few other places (the functions weren't
really properties, I just marked them
On Saturday, August 04, 2012 23:35:47 Adam D. Ruppe wrote:
OK, I just compiled one of my work apps with the hacked up dmd.
It caught me using properties as functions in a few places, which
I had to fix by removing the parenthesis from some places, and
the @property from a few other places
On 8/4/12, Jonathan M Davis jmdavisp...@gmx.com wrote:
snip
I agree with you. isSomeString!T predicate failing maybe isn't as
serious as !isSomeString!T passing and ending up with wrong results.
At the very least this should have been discussed about before the
change.
And why should a template
On Saturday, 4 August 2012 at 21:47:44 UTC, Jonathan M Davis
wrote:
If you can get properties working properly that quickly, that's
fantastic.
I did just realize I missed something but I'm convinced the
problem before is we were going at it at the wrong time, doing
the property rewrites
Go for it, man.
On 08/04/2012 11:09 PM, Jonathan M Davis wrote:
I agree that an enum's base type should not implicitly convert to the enum
type, since that would mean that you could have an invalid enum value, but I
see no problem with enums implicitly converted to their base type.
Well, there is a problem:
There was a very long discussion on this before that lead me to write this:
http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property
I should draw attention to the tables near the bottom. It is really too
bad that variables in D allow the taking of addresses by default. If
things were
On Saturday, 4 August 2012 at 15:12:54 UTC, bearophile wrote:
Andrei Alexandrescu:
I wasn't referring the clarity of explanation, just that I
think this sort of righteous pontification - cheap to produce,
yet implying vast insight - doesn't add any value to the
exchange.
I agree that my
On Sunday, August 05, 2012 00:15:02 Timon Gehr wrote:
On 08/04/2012 11:09 PM, Jonathan M Davis wrote:
I agree that an enum's base type should not implicitly convert to the enum
type, since that would mean that you could have an invalid enum value, but
I see no problem with enums implicitly
On Saturday, 4 August 2012 at 22:19:17 UTC, Chad J wrote:
There was a very long discussion on this before that lead me to
write this:
I'll have to read it... my thing right now works, as far as I can
tell, perfectly on free function properties.
But member properties are different and I
On Saturday, August 04, 2012 15:22:34 Jonathan M Davis wrote:
On Sunday, August 05, 2012 00:15:02 Timon Gehr wrote:
T fun(T)(T arg) if(isSomeString!arg){
return arg~arg[0];
}
Though honestly, I'd argue that the compiler should treat arg ~ arg[0] as
being string rather than the
On 08/04/2012 06:50 PM, Adam D. Ruppe wrote:
On Saturday, 4 August 2012 at 22:19:17 UTC, Chad J wrote:
There was a very long discussion on this before that lead me to write
this:
I'll have to read it... my thing right now works, as far as I can tell,
perfectly on free function properties.
On Saturday, 4 August 2012 at 16:11:45 UTC, Jacob Carlborg wrote:
On 2012-08-04 17:20, Kagamin wrote:
Dwarf2 exceptions work in clang+gcc on win32. It would be SOME
exception
handling (and quite interesting, I'd say).
This post recently appeared on the Clang mailing list:
Hi,
I have just
On Saturday, 4 August 2012 at 23:35:30 UTC, Hans W. Uhlig wrote:
On Saturday, 4 August 2012 at 16:11:45 UTC, Jacob Carlborg
wrote:
On 2012-08-04 17:20, Kagamin wrote:
Dwarf2 exceptions work in clang+gcc on win32. It would be
SOME exception
handling (and quite interesting, I'd say).
This
Does the standard library have any good non cryptographic hashing
functions? I am looking for something such as murmur3 or
equivalent?
On Tue, 31 Jul 2012 15:31:45 -0500, Jacob Carlborg d...@me.com wrote:
On 2012-07-31 19:30, Stuart wrote:
Of course it's *my* opinion. Whose else opinion would it be?
And that's just the point. I'm *not* using D. I *want* to be using D,
and I've been *trying* to use D, but I keep hitting
Adam D. Ruppe:
I should add: if a function is not marked @property, it should
not change at all: it should be callable with and without
parens,
I think I'd like functions not marked with @property to require
the ().
Bye,
bearophile
On Sunday, August 05, 2012 04:17:13 bearophile wrote:
Adam D. Ruppe:
I should add: if a function is not marked @property, it should
not change at all: it should be callable with and without
parens,
I think I'd like functions not marked with @property to require
the ().
I wholeheartedly
On Sunday, 5 August 2012 at 02:17:18 UTC, bearophile wrote:
I think I'd like functions not marked with @property to require
the ().
You have the -property switch for breaking piles of perfectly
good code while enabling no new functionality.
What I'm doing is completely independent of
On Sunday, August 05, 2012 04:25:26 Adam D. Ruppe wrote:
On Sunday, 5 August 2012 at 02:17:18 UTC, bearophile wrote:
I think I'd like functions not marked with @property to require
the ().
You have the -property switch for breaking piles of perfectly
good code while enabling no new
core.simd vectors are limited in a couple of annoying ways.
First, if I define:
@property pure nothrow
{
auto x(float4 v) { return v.ptr[0]; }
auto y(float4 v) { return v.ptr[1]; }
auto z(float4 v) { return v.ptr[2]; }
auto w(float4 v) { return v.ptr[3];
On Saturday, 4 August 2012 at 21:09:40 UTC, Jonathan M Davis
wrote:
I think that the change to std.traits was a big mistake and
will probably file it as a regression
I don't know what the right answer here is, but if you do end up
reverting those changes, be sure to change std.conv.to too so
Adam D. Ruppe:
You have the -property switch for breaking piles of perfectly
good code while enabling no new functionality.
The -property switch is present since lot of time, and I think
most people that write D2 code compile their libraries with
-property. So I don't think it breaks lot of
On Sunday, August 05, 2012 05:59:34 bearophile wrote:
Adam D. Ruppe:
You have the -property switch for breaking piles of perfectly
good code while enabling no new functionality.
The -property switch is present since lot of time, and I think
most people that write D2 code compile their
On Sunday, August 05, 2012 05:40:40 Adam D. Ruppe wrote:
On Saturday, 4 August 2012 at 21:09:40 UTC, Jonathan M Davis
wrote:
I think that the change to std.traits was a big mistake and
will probably file it as a regression
I don't know what the right answer here is, but if you do end up
Le 4 août 2012 00:50, David Nadlinger s...@klickverbot.at a écrit :
On Friday, 3 August 2012 at 22:23:23 UTC, Era Scarecrow wrote:
Seems like an ugly hack though (to get this done). Why not have another
method of fullpathStringof or something similar? Then again if this is one
of the few
On Saturday, August 04, 2012 09:57:36 Philippe Sigaud wrote:
For std.reflection that Andrei proposed 2 weeks ago, I feel the internal
code will contain many __traits() calls. Nothing to be done about it.
__traits is *the* way compile-time introspection is done in D.
That and std.traits.
Era Scarecrow rtcv...@yahoo.com
Then doesn't it seem like we're missing a potentially important piece of
the puzzle for mixins and templates? very likely my modified template will
include you including the same variable twice, but if someone gets lazy
then it may not work.
On Saturday, 4 August 2012 at 07:57:46 UTC, Philippe Sigaud wrote:
FWIW, I agree with David that using .stringof is a last resort
and can lead to nasty bugs. .stringof has a sometime incoherent
behavior (I remember it showing the entire code inside a
delegate literal)
But then, the code
On Saturday, 4 August 2012 at 08:06:31 UTC, Jonathan M Davis
wrote:
On Saturday, August 04, 2012 09:57:36 Philippe Sigaud wrote:
For std.reflection that Andrei proposed 2 weeks ago, I feel
the internal
code will contain many __traits() calls. Nothing to be done
about it.
__traits is *the* way
On Saturday, 4 August 2012 at 07:57:46 UTC, Philippe Sigaud wrote:
It uses __traits(parent, ) and __traits(qualifier, ), which are
much more
'modern' and well-behaved.
An example of what I mean: Try this with your CurryTemplate from
dranges:
---
import dranges.templates;
template Foo(A,
On Sat, 04 Aug 2012 03:01:31 +0200, Zeh zec...@yahoo.com.br wrote:
Thanks for the help, but i tryed both solutions posted and still not
working. :/
I get erros to compile the code posted by simendsjo. I try modify at my
own, but without success. The code suggest by Timon Gehr compiles, but
On Sat, Aug 4, 2012 at 10:25 AM, David Nadlinger s...@klickverbot.at wrote:
An example of what I mean: Try this with your CurryTemplate from dranges:
---
import dranges.templates;
template Foo(A, B) {
pragma(msg, A.stringof, , B.stringof);
}
alias CurryTemplate!Foo FooCurried;
On Saturday, 4 August 2012 at 11:29:36 UTC, Philippe Sigaud wrote:
Oh, I completely forgot this. Nice code, if I may say so myself
:)
Huh? It's broken, precisely because of the use of
__traits(identifier, …) in combination with string mixins. The
example doesn't compile.
David
On Sat, Aug 4, 2012 at 1:35 PM, David Nadlinger s...@klickverbot.at wrote:
On Saturday, 4 August 2012 at 11:29:36 UTC, Philippe Sigaud wrote:
Oh, I completely forgot this. Nice code, if I may say so myself :)
Huh? It's broken, precisely because of the use of __traits(identifier, …) in
Hi,
As I said on #d, foreach with __traits seems to ignore
ForeachTypeList's type.
Look at this ! :p
http://dpaste.dzfl.pl/0885e1de
Wtf ?
Thanks
On 04-Aug-12 17:57, Namespace wrote:
This code http://dpaste.dzfl.pl/6caed813 does only compile if i comment
out the Clone method. Why? o.O
Because it calls constructor and fails? I've done substitution for you:
this(const vec!(float,2) values) {
foreach (index, val; values) {
It looks like the problem is TypeTuple :
http://dpaste.dzfl.pl/de2264dd
1 - 100 of 160 matches
Mail list logo
