On Fri, Jan 23, 2009 at 12:30 AM, Bill Baxter wrote:
>
> I see what you're saying now. So the user has to manipulate a bool
> return value instead of an int?
>
> Then you could have
>
> void opApply(bool delegate(ref int) dg) {
> foreach(i; internal_) {
>if (dg(i)) return;
>
On Fri, Jan 23, 2009 at 11:59 AM, Jarrett Billingsley
wrote:
> On Thu, Jan 22, 2009 at 9:38 PM, Bill Baxter wrote:
>>
>> Yep, that was the gist of it. Put the return value on the stack of
>> the calling frame.
>> Nothing all that fancy really, just you want to be able to hide that
>> __result =
On Thu, Jan 22, 2009 at 9:38 PM, Bill Baxter wrote:
>
> Yep, that was the gist of it. Put the return value on the stack of
> the calling frame.
> Nothing all that fancy really, just you want to be able to hide that
> __result = blah ugliness from the user.
Oh, I'm suggesting that the compiler do
On 2009-01-19 18:11:15 -0500, Sergey Gromov said:
I think "can't" is a bit strong a statement. Let's see:
With opApply:
class progressUpdater(Collection)
{
this(Collection c)
{
collection_ = c;
}
int opApply(int delegate(ref ElementType!(Collection)) dg)
{
composed_ = dg;
On Fri, Jan 23, 2009 at 11:15 AM, Jarrett Billingsley
wrote:
> On Thu, Jan 22, 2009 at 7:00 PM, Bill Baxter wrote:
>>
>> I posted a proposal for how to hide the magic int from the user a
>> while back, but my conclusion was that my approach would require AST
>> macros in order to give it a reason
On Thu, Jan 22, 2009 at 8:13 PM, Stewart Gordon wrote:
> Don wrote:
>
>>
>> The other option (which I would prefer) is for druntime to get bigger, and
>> encompass more of the common code from both. So that both Phobos and Tango
>> became (crucial) extension libraries over a small core. And the b
On Thu, Jan 22, 2009 at 7:00 PM, Bill Baxter wrote:
>
> I posted a proposal for how to hide the magic int from the user a
> while back, but my conclusion was that my approach would require AST
> macros in order to give it a reasonable syntax. With the ast macros
> you'd be able to do something li
Don wrote:
The other option (which I would prefer) is for druntime to get bigger,
and encompass more of the common code from both. So that both Phobos and
Tango became (crucial) extension libraries over a small core. And the
bigger that common core becomes, the smaller the library problem beco
"bearophile" wrote in message
news:gl0ohe$1gd...@digitalmars.com...
>I think pluggable type systems will become more common in the following
>years (see also the optional annotations of Python3 that are designed for
>that too). This is more or less related:
>
> http://bartoszmilewski.wordpress.
On Fri, Jan 23, 2009 at 8:52 AM, Ary Borenszweig wrote:
> Bill Baxter wrote:
>>
>> On Fri, Jan 23, 2009 at 8:10 AM, Christopher Wright
>> wrote:
>>>
>>> Ary Borenszweig wrote:
If the compiler can transform a "foreach" into an opApply call, passing
the foreach body and converting br
Bill Baxter wrote:
On Fri, Jan 23, 2009 at 8:10 AM, Christopher Wright wrote:
Ary Borenszweig wrote:
If the compiler can transform a "foreach" into an opApply call, passing
the foreach body and converting breaks to "return 1" statements... can't
opApply be specified as:
int opApply(void deleg
On Fri, Jan 23, 2009 at 8:10 AM, Christopher Wright wrote:
> Ary Borenszweig wrote:
>>
>> If the compiler can transform a "foreach" into an opApply call, passing
>> the foreach body and converting breaks to "return 1" statements... can't
>> opApply be specified as:
>>
>> int opApply(void delegate(
Ary Borenszweig wrote:
If the compiler can transform a "foreach" into an opApply call, passing
the foreach body and converting breaks to "return 1" statements... can't
opApply be specified as:
int opApply(void delegate(ref uint) dg) { // note: delegate returns void
}
and the compiler transfor
Denis Koroskin Wrote:
> I think believe we could take advantage of current state of both libraries in
> D2 - they are both incomplete and being redesigned to fit D2 better.
> We could revisit both Tango and Phobos, and clean them up by removing
> outdated modules and modules with same functional
On Thu, 22 Jan 2009 18:11:02 +0100, Jarrett Billingsley
wrote:
On Thu, Jan 22, 2009 at 1:53 AM, Alexander Pánek
wrote:
John Reimer wrote:
Don wrote:
The other option (which I would prefer) is for druntime to get bigger,
and encompass more of the common code from both. So that both Phobo
Jarrett Billingsley schrieb:
> As far as most people can tell, it's an artifact from very early on in
> D's development. It was probably originally supposed to have MI but
> that was dropped. The compiler accepts public/private/protected on
> the base class but it's useless as it breaks things.
Sergey Gromov wrote:
Mon, 19 Jan 2009 06:15:06 -0800, Andrei Alexandrescu wrote:
Michel Fortin wrote:
Other possible things involves a rudimentary profiler (checking for the
elapsed time at each loop iteration), or a progress monitoring template
(notifying another thread of the progress of a
On Thu, Jan 22, 2009 at 1:53 AM, Alexander Pánek
wrote:
> John Reimer wrote:
>>
>> Don wrote:
>>>
>>> The other option (which I would prefer) is for druntime to get bigger,
>>> and encompass more of the common code from both. So that both Phobos
>>> and Tango became (crucial) extension libraries o
Don wrote:
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Don wrote:
[snip]
It means that any code which uses a library based on both Tango and a
library based on Phobos will end up with two copies of all of the
functions, and they'll have different name mangling etc. You end up
with two inco
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Don wrote:
[snip]
It means that any code which uses a library based on both Tango and a
library based on Phobos will end up with two copies of all of the
functions, and they'll have different name mangling etc. You end up
with two incompatible Big
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
IUnknown wrote:
Regarding Phobos + Tango, the minimum I expect is things like
containers, algorithm and common math stuff to be in one core module.
This is already bound to be an issue be
On Thu, Jan 22, 2009 at 9:43 AM, Harry Vennik wrote:
> Hi,
>
>
> http://www.digitalmars.com/d/2.0/class.html
>
> In the grammar specification I read that a base class or interface name can
> be prepended a protection attribute. But I don't find a word about the
> semantics thereof... Can anyone
On Sun, Jan 18, 2009 at 11:11 PM, Stewart Gordon wrote:
> ...
> Speaking of which, has anybody tried asking Brad for commit permission on
> an abandoned project in order to revive it?
>
> Stewart.
>
I took over the MinWin project a long time ago, since its author, Ben
Hinkle, had disappeared from
Andrei Alexandrescu wrote:
> Don wrote:
>> [snip]
>>
>> It means that any code which uses a library based on both Tango and a
>> library based on Phobos will end up with two copies of all of the
>> functions, and they'll have different name mangling etc. You end up
>> with two incompatible Bigint
Hi,
http://www.digitalmars.com/d/2.0/class.html
In the grammar specification I read that a base class or interface name can be
prepended a protection attribute. But I don't find a word about the semantics
thereof... Can anyone tell (and update the docs)?
Regards,
Harry
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
IUnknown wrote:
Regarding Phobos + Tango, the minimum I expect is things like
containers, algorithm and common math stuff to be in one core module.
This is already bound to be an issue because there is disagreement
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Can we work out the math stuff at least? There's no difference
between Phobos and Tango there. All we need is an agreement on common
module naming (eg, create core.math).
That would be great. I don't think that's a major issue anyway. If I
we
BCS Wrote:
> Hello dsimcha,
>
> > Just curious, why doesn't D, and why don't more statically typed
> > languages in general, support overload by return type? I haven't
> > exactly thought through all the pros and cons, but at first glance it
> > seems like an incredibly useful thing. What's the
Denis Koroskin pisze:
On Thu, 22 Jan 2009 09:18:52 +0300, Benji Smith
wrote:
IUnknown wrote:
Agree. Which is why I said the problems you are facing seem to be
non-technical. I'm suggesting that the D library developers should
pick one and axe the other. *I* think what more important is to h
On Thu, 22 Jan 2009 09:18:52 +0300, Benji Smith
wrote:
IUnknown wrote:
Agree. Which is why I said the problems you are facing seem to be
non-technical. I'm suggesting that the D library developers should pick
one and axe the other. *I* think what more important is to have one
single set
Walter Bright pisze:
Setting aside the technical issues for the moment, I'd like to go back
to the notion that structs are for compile time polymorphism and classes
are for runtime polymorphism. Template functions are clearly in the
compile time camp, and if you need compile time polymorphism i
31 matches
Mail list logo
