Jerry Quinn wrote:
> Hi, all. I find myself a little confused about how foreach, opApply, and
> delegates interact according to the docs.
>
> Foreach on an aggregate will use the opApply call (assuming ranges aren't
> being used). So if we use a simple example below, what exactly is the
> del
Don wrote:
> Steve Teale wrote:
>> To the D Faithful:
>>
>> In recent postings, I have increasingly seen references to the
>> 'Select Few'.
>>
>> This kind of reminds me of Iran, where you have 'The Guardian
> Council', and 'The Supreme Leader'.
>
> The similarities are pretty weak, I'd say.
> Wh
dsimcha wrote:
> I know I've probably mentioned this one here before, but it was buried in long
> threads.
>
> Could we put a feature in the language that allows private member variables to
> be cast to public? The idea is that, if a class/struct designer makes
> something private, they're saying
Ary Borenszweig wrote:
> downs escribió:
>> dsimcha wrote:
>>> I know I've probably mentioned this one here before, but it was
>>> buried in long
>>> threads.
>>>
>>> Could we put a feature in the language that allows private member
>
Bill Baxter wrote:
> Just remembered this other real example of a D property that caused me
> discomfort:
>
> .transform
>
> I wanted it to be an unambiguous property that returns the transform
> of an object, but it's too easy to misinterpret as an action that
> transforms the object if it can
Bill Baxter wrote:
> On Wed, Jul 29, 2009 at 8:11 AM, downs wrote:
>> Bill Baxter wrote:
>>> Just remembered this other real example of a D property that caused me
>>> discomfort:
>>>
>>> .transform
>>>
>>> I wanted it to be an u
In this post, I present a simple rule of thumb that covers most cases of the
common decision: should a feature go in the compiler, or in the standard
library?
Note: this only applies to features that aren't in C.
1) If it's a word, put it in the standard library.
2) Otherwise, put it in the com
Walter Bright wrote:
> downs wrote:
>> As it stands, the claim on the homepage that it's easier to implement
>> a D compiler than a C++ one is highly dubious.
>
> Since I'm the only person to have implemented both, I think I'm in a
> good position to judge
language_fan wrote:
> Thu, 30 Jul 2009 21:57:33 +0200, downs thusly wrote:
>
>> As it stands, the claim on the homepage that it's easier to implement a
>> D compiler than a C++ one is highly dubious.
>
> Isn't D simpler to implement than C++ because the
To clarify for a few criticisms that have come up in IRC: this is meant as a
rule of thumb to fall back on where no other considerations are present.
For instance, const and shared are type constructors, and as such hard to do in
the standard library.
To my knowledge, assert() for instance has
downs wrote:
> Walter Bright wrote:
>> downs wrote:
>>> As it stands, the claim on the homepage that it's easier to implement
>>> a D compiler than a C++ one is highly dubious.
>> Since I'm the only person to have implemented both, I think I'm in a
Michiel Helvensteijn wrote:
> downs wrote:
>
>> 1) If it's a word, put it in the standard library.
>> 2) Otherwise, put it in the compiler.
>
> What an interesting theory.
>
>> For example:
>>
>> assert() -> library.
>
> Compile-tim
Lars T. Kyllingstad wrote:
> downs wrote:
>> To clarify for a few criticisms that have come up in IRC: this is
>> meant as a rule of thumb to fall back on where no other considerations
>> are present.
>>
>> For instance, const and shared are type constructors,
Sergey Gromov wrote:
> Thu, 30 Jul 2009 21:57:33 +0200, downs wrote:
>
>> 1) If it's a word, put it in the standard library.
>> 2) Otherwise, put it in the compiler.
>>
>> For example:
>>
>> assert() -> library.
>> complex -> library.
&g
Leandro Lucarella wrote:
> downs, el 30 de julio a las 22:31 me escribiste:
>> To clarify for a few criticisms that have come up in IRC: this is meant as a
>> rule of thumb to fall back on where no other considerations are present.
>>
>> For instance, const and shared
grauzone wrote:
> Daniel Keep wrote:
>>
>> grauzone wrote:
>>> torhu wrote:
On 03.08.2009 19:47, Andrei Alexandrescu wrote:
> A while ago I mentioned the video of my BoostCon keynote "Iterators
> Must
> Go" will be soon available online. Here it is:
>
> http://boostcon.blip
BCS wrote:
> Reply to Jarrett,
>
>> On Mon, Aug 17, 2009 at 7:42 PM, Paul D.
>> Anderson wrote:
>>> It's awfully quiet on the newsgroup today. Does that mean Walter is
>>> busy getting the new release ready?
>>>
>>> Or does it only mean I'm not getting new posts :(
>>>
>>> Suspiciously,
>>>
>>> Pa
Lars T. Kyllingstad wrote:
> Tim Matthews wrote:
>> Jarrett Billingsley Wrote:
>>
>>> On Mon, Aug 17, 2009 at 7:42 PM, Paul D.
>>> Anderson wrote:
It's awfully quiet on the newsgroup today. Does that mean Walter is
busy getting the new release ready?
Or does it only mean I'm not
Walter Bright wrote:
> Jeremie Pelletier wrote:
>> Isn't it possible to make 'const ref S' or 'in S' generate the same
>> machine code as 'in S*'? To me it would seem the semantics of the two
>> are the same, with 'const S*' being useful syntax for C compatibility
>> while 'in S' and 'const ref S'
I think a favorite line of D code should have a feature of D that
>> doesn't appear in any other language...
>
> I've heard a d guru known as 'downs' is the master of obfuscated one-
> liners.
Well I wouldn't call myself a 'guru' .. 'mutilator&#
Robert Fraser wrote:
> downs wrote:
>> foo.betweens("src=\"", "\"") /select/ (string s) { return
>> s.find(criteria) != -1; }
>
> Heh, I love that infix expression syntax. Too abd it ends up with a
> completely useless wrapper struct &
Justin Johansson wrote:
> Can D people please recommend suitable tools for generating a parser (in D)
> for an LL(1) grammar. There's bound to be much better parser generator tools
> available nowadays, since my last foray into this area 10+ years ago with
> YACC. I've heard of tools like biso
Justin Johansson wrote:
> > downs Wrote:
> >
>> >> Justin Johansson wrote:
>>> >>> Can D people please recommend suitable tools for generating a parser
>>> >>> (in D) for an LL(1) grammar. There's bound to be much better parser
Justin Johansson wrote:
>downs Wrote:
>>
>> Justin Johansson wrote:
>>> Can D people please recommend suitable tools for generating a parser (in D)
>>> for an LL(1) grammar. There's bound to be much better parser generator
>>> tools available
Nick Sabalausky wrote:
> "Justin Johansson" wrote in message
> news:h8ruu1$1qp...@digitalmars.com...
>> Being somewhat of a fan of Elliotte Rusty Harold, I drop in for a coffee &
>> read at his cafes from time to time. I think D people will enjoy this
>> December 2008 article with amusement so
language_fan wrote:
> Sun, 20 Sep 2009 18:16:37 -0400, bearophile thusly wrote:
>
>> My benchmarks aren't chosen randomly, I naturally focus on things that
>> are slower in D, so sometimes you can see Java to "win". I usually
>> discard the code where Java results slower :-)
>
> I have seen peopl
With all the neat template tricks we have in 2.0, and since we're widely
redefining the syntax anyway, why not deprecate the current cast syntax and
move it into object.d as a library function?
So instead of cast(Foo) bar; you would say cast!Foo(bar); .. save on a keyword
and demonstrate langua
Andrei Alexandrescu wrote:
> downs wrote:
>> With all the neat template tricks we have in 2.0, and since we're
>> widely redefining the syntax anyway, why not deprecate the current
>> cast syntax and move it into object.d as a library function?
>>
>> So instea
bearophile wrote:
> Justin Johansson:
>> See subject line
>
> You can't. All questions here will be scrupulously scrubbed, looking for
> subversive ideas or hidden irony, and if something is found they invariably
> spout and blossom into invasive threads of often pointless but interesting
> dis
Jeremie Pelletier wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> downs wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> downs wrote:
>>>>>> With all the neat template tricks we have in 2.0, and since we're
>&
language_fan wrote:
> Thu, 24 Sep 2009 13:47:21 -0400, Steven Schveighoffer thusly wrote:
>
>> I actually prefer the compiler to handle the casting versus templates to
>> cut down on template instantiation bloat.
>
> I wonder how D scales to 100 MLOC programs as the template instantiations
> can
Jeremie Pelletier wrote:
> downs wrote:
>> Jeremie Pelletier wrote:
>>> grauzone wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> downs wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> downs wrote:
>>>>&
Jeremie Pelletier wrote:
> downs wrote:
>> Jeremie Pelletier wrote:
>>> downs wrote:
>>>> Jeremie Pelletier wrote:
>>>>> grauzone wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> downs wrote:
>>>>>&g
Walter Bright wrote:
> Nick Sabalausky wrote:
>
> I agree with you that if the compiler can detect null dereferences at
> compile time, it should.
>
>
>>> Also, by "safe" I presume you mean "memory safe" which means free of
>>> memory corruption. Null pointer exceptions are memory safe. A null
>
Denis Koroskin wrote:
> On Sun, 27 Sep 2009 03:01:48 +0400, Walter Bright
> wrote:
>
>> Denis Koroskin wrote:
>>> One more:
>>> T foo(bool someCondition)
>>> {
>>> T? t;
>>> if (someCondition) t = someInitializer();
>>> // ...
>>> if (t.isNull) { // not initialized yet
>>>
Jeremie Pelletier wrote:
> Jarrett Billingsley wrote:
>> On Sat, Sep 26, 2009 at 11:23 PM, Jeremie Pelletier
>> wrote:
>>
>>> There is no such thing as "not being able to happen" :)
>>>
>>> Object thisCannotPossiblyBeNullInAnyWayWhatsoever = cast(Object)null;
>>>
>>> I seem to be the only one who
Jeremie Pelletier wrote:
> Christopher Wright wrote:
>> Jeremie Pelletier wrote:
>>> What if using 'Object obj;' raises a warning "unitialized variable"
>>> and makes everyone wanting non-null references happy, and 'Object obj
>>> = null;' raises no warning and makes everyone wanting to keep the
>>
Jeremie Pelletier wrote:
> Andrei Alexandrescu wrote:
>> downs wrote:
>>> Walter Bright wrote:
>>>> Nick Sabalausky wrote:
>>>>
>>>> I agree with you that if the compiler can detect null dereferences at
>>>> compile time, it should
Jeremie Pelletier wrote:
> downs wrote:
>> Jeremie Pelletier wrote:
>>> Christopher Wright wrote:
>>>> Jeremie Pelletier wrote:
>>>>> What if using 'Object obj;' raises a warning "unitialized variable"
>>>>> an
Jeremie Pelletier wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> Here's an article about the perils of equals in Java (opEquals in D):
>>>
>>> http://www.ddj.com/article/printableArticle.jhtml;jsessionid=GFKUCQH5S4IHNQE1GHOSKHWATMY32JVN?articleID=184405053&dept_url=/java/
>>>
>>>
>>> It
language_fan wrote:
> Fri, 02 Oct 2009 19:35:55 -0300, Leandro Lucarella thusly wrote:
>
>> We might have very different taste, but I find that a little...
>> horrible. What do you have against mixins? I think you're trying to use
>> D as C++ :)
>
> So basically the diamond problem is again imple
Justin Johansson wrote:
> Walter Bright Wrote:
>
>> http://www.reddit.com/r/programming/comments/9qf8i/i_wrote_some_d_today_and_its_completely_blowing/
>
> Don't know why you bother with Reddit, Walter. Going by a lot of the replies
> there, its a case of
> pearls before swine.
>
> Cheers
> --
Denis Koroskin wrote:
> I'm currently writing a program that interfaces with C++.
> C++ code uses a lot of 'unsigned long', which equals to 'unsigned int',
> or just 'unsigned', but is mangled differently.
>
> In particular, C++ mangles unsigned long as 'K', and I can't find a D
> counterpart that
bearophile wrote:
> Denis Koroskin:
>
>> I don't see any reason why if (someComplexNumber) { ... } should be a
> valid code, it hardly makes any sense for me.<
>
> In general I think adding a boolean-evaluation standard method to D can be
> positive and handy and not that bug-prone.
> But comp
Andrei Alexandrescu wrote:
> Hello,
>
>
> D currently allows defining class allocators and deallocators. They have
> a number of problems that make them unsuitable for D 2.0. The most
> obvious issue is that D 2.0 will _not_ conflate destruction with
> deallocation anymore: invoking delete agains
Andrei Alexandrescu wrote:
> downs wrote:
>> Andrei Alexandrescu wrote:
>>> Hello,
>>>
>>>
>>> D currently allows defining class allocators and deallocators. They have
>>> a number of problems that make them unsuitable for D 2.0. The mo
Andrei Alexandrescu wrote:
> downs wrote:
>> Andrei Alexandrescu wrote:
>>> downs wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> Hello,
>>>>>
>>>>>
>>>>> D currently allows defining class allocators and dealloc
Don wrote:
> downs wrote:
>> Andrei Alexandrescu wrote:
>>> downs wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> downs wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> Hello,
>>>>>>>
>>>
Jeremie Pelletier wrote:
> downs wrote:
>> Don wrote:
>>> downs wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> downs wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> downs wrote:
>>>>>>>>
Did you know the following code compiles?
> module test;
>
> import std.stdio;
>
> void Assert(bool cond, string delegate()[] dgs...) {
> debug if (!cond) {
> string str;
> foreach (dg; dgs) str ~= dg();
> throw new Exception(str);
> }
> }
>
> void main() {
> Assert(false, "O hai
downs wrote:
> Did you know the following code compiles?
>
>> module test;
>>
>> import std.stdio;
>>
>> void Assert(bool cond, string delegate()[] dgs...) {
>> debug if (!cond) {
>> string str;
>> foreach (dg; dgs) str ~= dg();
&
Jeremie Pelletier wrote:
> Andrei Alexandrescu wrote:
>> Chris Nicholson-Sauls wrote:
>>> downs wrote:
>>>>
>>>> Here is a funny consequence of this amusing fact:
>>>>
>>>> if you overload opAssign in a stru
Justin Johansson wrote:
> - that the .sizeof a delegate is 8 bytes (on a 32-bit machine).
>
> AFAIK, stack pushes are still more expensive than a pointer dereference in
> contemporary
> CPU architectures.
>
> Justin
- with this weird way of writing posts? The subject should tell us about the
c
Two discoveries were made from this benchmark.
1) There is no appreciable speed difference between delegates and functors. I
re-ran the benchmark several times; sometimes one was faster, sometimes the
other - no clear advantage was discernible. The visible differences can be
blamed on experimen
On consideration, this wasn't a test of the two methods at all, but a test of
the compiler's ability to inline. Disregard it.
Gemaine Frazier wrote:
> completely chilled - a glass or two of wine will do that...
you all! Except you, weird spacey goat thing. You freak me out.
But man this is some FINE weed!
Jeremie Pelletier wrote:
> Nick Sabalausky wrote:
>> "downs" wrote in message
>> news:hb83h6$1ht...@digitalmars.com...
>>> Gemaine Frazier wrote:
>>>> completely chilled - a glass or two of wine will do that...
>>> you all! Except you, wei
Walter Bright wrote:
> The purpose of T[new] was to solve the problems T[] had with passing T[]
> to a function and then the function resizes the T[]. What happens with
> the original?
>
> The solution we came up with was to create a third array type, T[new],
> which was a reference type.
>
> And
dsimcha wrote:
> == Quote from downs (default_357-l...@yahoo.de)'s article
>> Walter Bright wrote:
>>> The purpose of T[new] was to solve the problems T[] had with passing T[]
>>> to a function and then the function resizes the T[]. What happens with
>>> t
Walter Bright wrote:
> Ary Borenszweig wrote:
>> I remember seeing a lot of CTFE code that created a dynamic array and
>> then appended stuff to it, like for example to build a list of prime
>> numbers. Would that still work with ArrayBuilder?
>
> Probably not. But you can rewrite:
>
> a ~= stu
Walter Bright wrote:
> Currently, static arrays are (as in C) half-value types and
> half-reference types. This tends to cause a series of weird problems and
> special cases in the language semantics, such as functions not being
> able to return static arrays, and out parameters not being possible
sprucely wrote:
> To try to be sure I had the correct syntax I tried the -S option of g++ along
> with a switch for intel syntax to output the assembly. However the portion
> corresponding to the inline assembly was still in ATT syntax.
>
> For my resulting D executable I tried using hte, but it
AJ wrote:
> "Nick Sabalausky" wrote in message
> news:hboum3$1bh...@digitalmars.com...
>> "AJ" wrote in message
>> news:hbosh1$17l...@digitalmars.com...
>>> "Nick Sabalausky" wrote in message
>>> news:hbontv$uq...@digitalmars.com...
If you want to manually write a separate redundant file
Walter Bright wrote:
> http://langref.org/
>
> Need some D versions!
http://rosettacode.org/wiki/Category:D is much more complete.
I submitted a patch a while back for constant-time removeRange. Can we dredge
that one up and/or implement something similar? It's rather useful for things
like stackthreads that need to add and remove lots of ranges :)
(Search the NG for "Feature req.+Patch: O(1) removeRange")
dsimcha wrote:
> == Quote from downs (default_357-l...@yahoo.de)'s article
>> I submitted a patch a while back for constant-time removeRange. Can we dredge
> that one up and/or implement something similar? It's rather useful for things
> like
> stackthreads that ne
dsimcha wrote:
> == Quote from downs (default_357-l...@yahoo.de)'s article
>> dsimcha wrote:
>>> == Quote from downs (default_357-l...@yahoo.de)'s article
>>>> I submitted a patch a while back for constant-time removeRange. Can we
>>>> dredg
auto var = hairilyAllocatedObject();
scope(exit) cleanupObject(var);
sock.send("");
scope(exit) sock.send("");
logln("Digraph D {");
scope(exit) logln("}");
SDL_LockSurface(display.surface);
scope(exit) SDL_UnlockSurface(display.surface);
auto dg = { performComplexExitCleanupDuty; };
scope(exit
Justin Johansson wrote:
> downs Wrote:
>
>> auto var = hairilyAllocatedObject();
>> scope(exit) cleanupObject(var);
>>
>> sock.send("");
>> scope(exit) sock.send("");
>>
>> logln("Digraph D {");
>> scope(exit)
amaury pouly wrote:
> Hello,
> I have a little question about D: I want to have a function returning a
> delegate and more precisely a delegate literal that uses one of the arguments
> of the function. Here is an example:
>
> int delegate(int) test(int[] tab)
> {
> return (int d)
> {
>
This has been brought up before as an argument against the !in operator
(forcing us to resort to such workarounds as /notin/): that the !in operator
would have inconsistent syntax with in, because in returns a pointer and !in
would return a bool.
This is NOT a reason against !in. In fact, this
Rainer Deyke wrote:
> downs wrote:
>> This is NOT a reason against !in. In fact, this so-called
>> "inconsistency" is already present in the language. If we remember,
>> !pointer already transforms it into a boolean, so it would actually
>> be more consistent i
Bill Baxter wrote:
> On Sat, Feb 7, 2009 at 8:54 AM, bearophile wrote:
>> Rainer Deyke:
>>> It's a question of consistent patterns versus special cases.
>> You may think that for humans it's better to have a very orthogonal
>> language, like for example Scheme.
>> There's also a famous quote abou
Weed wrote:
> Christopher Wright пишет:
>> Weed wrote:
>>> Christopher Wright пишет:
Weed wrote:
> (Has started here:
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81359)
>
>
>
> To me still does not give rest performance of clas
Daniel Keep wrote:
> Andrei Alexandrescu wrote:
>> Denis Koroskin wrote:
>>> On Thu, 19 Feb 2009 22:25:04 +0300, Mattias Holm
>>> wrote:
>>>
Since (SIMD) vectors are so common and every reasonabe system support
them in one way or the other (and scalar emulation of this is rather
sim
Let me say first that I don't use std.bind myself, but tools.base:fix fills
essentially the same need - creating full closures from dynamic ones.
Say you have a function that takes a number and returns a delegate that does
something with that number.
void delegate() test(int i) { return { retur
Yigal Chripun wrote:
> Lars Kyllingstad wrote:
>> I've always thought currying was the main point of std.bind. If I'm not
>> mistaken, currying is commonly a built-in feature of functional
>> programming languages, so if anything, std.bind could become more
>> useful/important in D2 than in D1.
>>
Andrei Alexandrescu wrote:
> bearophile wrote:
>> As an alternative syntax may be:
>>
>> foreach (i; 1:10) {...}
>> foreach (i; 10 : 1 : -1) {...}
>> foreach (i; 0.0 : 10.5 : 0.5) {...}
>
> I have an idea - we define a contextual keyword "iota" that helps us
> specify from, to, and stride. Then we
Andrei Alexandrescu wrote:
> D is positioned very well, probably uniquely, to take advantage of a
> default-isolated model within a largely mutative language, and that is
> in no small part due to const and immutable. Other languages are
> struggling, see http://tinyurl.com/4apat7. I'm very glad th
dsimcha wrote:
> Is opImplicitCast (and fixing opCast) anywhere in the pipeline? It seems like
> every time I want to create an interesting library type, lack of
> opImplicitCast prevents me from making its API nice enough to be worth doing.
> In some cases, alias this, which has been proposed,
struct Temp(T) {
T t;
}
T* allocate(T)() {
auto wrap = new Temp!(T);
return &wrap.t;
}
davidl wrote:
>
> Actually I'm not sure about what kind of bugs my d apps usually have.
> But I notice that the harmonia project(I now make it uptodate) gets the
> problem of integer overlapping(actually I find it quite hard to detect
> and fix).
>
> What's your opinion and experience?
I'd say i
Qian Xu wrote:
> Hi All,
>
> Is minimal evaluation always enabled in D?
>
> I want to write a function IsNull(), so that I can check the precondition as
> follows:
>
> if (isNull(foo) ||
> isNull(foo.getBar) ||
> isNull(foo.getBar.getBar2)
> {
> return false;
> }
> // nor
Daniel Keep wrote:
>
> downs wrote:
>> Qian Xu wrote:
>>> Hi All,
>>>
>>> Is minimal evaluation always enabled in D?
>>>
>>> I want to write a function IsNull(), so that I can check the precondition as
>>> follows:
>>>
Ellery Newcomer wrote:
> Baas wrote:
>> Tech info:
>> - Parse the code into XML using Regular Expressions.
>
> *double take*
It's all about the better optimizations that are now possible!
Bass wrote:
> downs Wrote:
>
>> Ellery Newcomer wrote:
>>> Baas wrote:
>>>> Tech info:
>>>> - Parse the code into XML using Regular Expressions.
>>> *double take*
>> It's all about the better optimizations that are now possible!
&
TomD wrote:
> Qian Xu Wrote:
>
>> Hi All,
>>
>> Is minimal evaluation always enabled in D?
>>
>> I want to write a function IsNull(), so that I can check the precondition as
>> follows:
>>
>> Â if (isNull(foo) ||
>> Â Â Â isNull(foo.getBar) ||
>> Â Â Â isNull(foo.getBar.getBar2)
>> Â {
>>
Andrei Alexandrescu wrote:
> Denis Koroskin wrote:
>> On Fri, 17 Apr 2009 18:24:04 +0400, Steven Schveighoffer
>> wrote:
>>
>>> On Fri, 17 Apr 2009 09:44:09 -0400, Leandro Lucarella
>>> wrote:
>>>
I don't fully understand the example though. In writefln((v.qq = 5).i),
how is that B.i i
bearophile wrote:
> downs:
>> Static loops are simple, at least in functions.
>> ...
>> void main() {
>> foreach (i, bogus; Repeat!(void, 15))
>> writefln(i);
>> }
>
> My dlibs have:
> Range!([start], stop[, step])
> with it I think you
Daniel Keep wrote:
>
> bearophile wrote:
>> downs:
>>> bearophile:
>>>> But a static foreach (on a static data structure that has opApply) is not
>>>> doable yet, I think.
>>> Foreach on a tuple is evaluated at compile-time.
>> Yes, t
Denis Koroskin wrote:
> What's a rationale behind an issue described bug 2621?
> http://d.puremagic.com/issues/show_bug.cgi?id=2621
>
> Why isn't it allowed anymore?
>
> It broke quite a lot of my code. And while it is fixable by doing
>
> auto tmp = someFunctionThatRetunsStruct();
> someMethodT
I just committed tools/remake.d. What it does in a nutshell is this:
it lets you add a call in your main.d file, along the lines of
checkRemake(args, "path/to/source/file.d");
checkRemake invokes gdc (or a compiler of choice, via string Compiler), in
verbose mode, to generate a list of import
Saaa wrote:
> Instead of running build/bud you could run your old program to rebuild
> itself?
>
That's the idea! :)
>> I just committed tools/remake.d. What it does in a nutshell is this:
>>
>> it lets you add a call in your main.d file, along the lines of
>>
>> checkRemake(args, "path/to/sou
Nick Sabalausky wrote:
> "Daniel Keep" wrote in message
> news:gt159p$1bq...@digitalmars.com...
>>
>> Penguin wrote:
>>> What do you think about:
>>>
>>> class Foo {
>>>
>>>int a;
>>>float b;
>>>
>>>this( member a, member b ) {
>>>
>>>}
>>>
>>> }
>>>
>>> instead of:
>>>
>>> class
DisForDave wrote:
> downs Wrote:
>
>> Nick Sabalausky wrote:
>>> "Daniel Keep" wrote in message
>>> news:gt159p$1bq...@digitalmars.com...
>>>> Penguin wrote:
>>>>> What do you think about:
>>>>>
>>>>
Dan900 wrote:
> I tried to compile this code using
>
> gdc -o dodawanie dodawanie.d
>
> import std.stdio;
> void main() {
> int a = 6, b = 7;
> writefln(a+b); // wynik dodawania nie zostanie zapisany do zmiennej
> // tylko od razu przekazany funkcji writefln
bearophile wrote:
> dsimcha Wrote:
>> I've been thinking a little more about ranges, etc. and it would be nice to
>> have a template for isIterable(T)
>
> I agree.
> IsIterable is already inside my dlibs (as the xkeys/xvalues you talk about in
> another post of yours, but in the "func" module), i
Andrei Alexandrescu wrote:
> bearophile wrote:
>> Andrei Alexandrescu:
>>> Splitter does what Perl's split does: 2.
>>
>> Perl has to die. This is Python:
>
> This answer is wrong for a number of reasons. First comes the fallacy
> that if Perl "has to die", everything Perl did was wrong. Second co
Daniel Keep wrote:
>
> Michel Fortin wrote:
>> On 2009-04-27 10:51:22 -0400, Frits van Bommel
>> said:
>>
>>> I edited this code to work with ldc (D1) + Tango, and saw the Direct
>>> and opApply cases generate identical code (inc, cmp, jne, with the
>>> loop counter in a register) [1], so they're
Joel C. Salomon wrote:
> grauzone wrote:
>> downs wrote:
>>> Daniel Keep wrote:
>>>> Here's an excellent reason to use ranges over opApply: you
>>>> can't define zip with opApply. Because opApply uses inversion of
>>>> contro
1 - 100 of 137 matches
Mail list logo
