Jason House wrote:
Andrei Alexandrescu Wrote:
Jason House wrote:
BCS wrote:
Hello Jason,
Should the final freezing of D2 be delayed until major D1 libraries
port to D2? I'm mostly thinking of Tango, but I bet there are others.
It may even be good if major libraries could use a Phobos-compa
Don wrote:
> bearophile wrote:
>> Andrei Alexandrescu:
>>> there's been a sharp increase in bug reports and patches recently.
>>> Walter and I are still scratching our head over that (it's not like
>>> dmd got much crappier overnight). I can only infer that more people
>>> have started using more o
bearophile wrote:
Andrei Alexandrescu:
there's been a sharp
increase in bug reports and patches recently. Walter and I are still
scratching our head over that (it's not like dmd got much crappier
overnight). I can only infer that more people have started using more of D.
I think it's mostly
Guillaume B. wrote:
Andrei Alexandrescu wrote:
For starters, I'd like to present you with the following challenge.
Given any class C, e.g.:
class C
{
void foo(int) { ... }
int bar(string) { ... }
}
define a template class Finalize(T) such that Finalize!(C) is the same
as the followin
Andrei Alexandrescu Wrote:
> Jason House wrote:
> > BCS wrote:
> >
> >> Hello Jason,
> >>
> >>> Should the final freezing of D2 be delayed until major D1 libraries
> >>> port to D2? I'm mostly thinking of Tango, but I bet there are others.
> >>> It may even be good if major libraries could use a
Andrei Alexandrescu:
> there's been a sharp
> increase in bug reports and patches recently. Walter and I are still
> scratching our head over that (it's not like dmd got much crappier
> overnight). I can only infer that more people have started using more of D.
I think it's mostly a complex con
Andrei Alexandrescu wrote:
>
> For starters, I'd like to present you with the following challenge.
> Given any class C, e.g.:
>
> class C
> {
> void foo(int) { ... }
> int bar(string) { ... }
> }
>
> define a template class Finalize(T) such that Finalize!(C) is the same
> as the follow
"Andrei Alexandrescu" wrote in message
news:gv7j9t$m9...@digitalmars.com...
Lionello Lunesu wrote:
Andrei Alexandrescu wrote:
[snip]
Given the bad reputation that pointers have, I guess people wouldn't
like this all that much.
You don't need a pointer to T, you need a nullable T :)
...whi
"Steven Schveighoffer" wrote in message
news:op.uucxvnxleav...@steves.networkengines.com...
On Fri, 22 May 2009 20:43:22 -0400, Lionello Lunesu
wrote:
[snip]
You don't need a pointer to T, you need a nullable T :)
...which doesn't exist...
No, you need a pointer. If T is a reference type
Steven Schveighoffer wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Fri, 22 May 2009 21:22:55 -0400, Andrei Alexandrescu
wrote:
1. Any range should be seamlessly and efficiently used as an input
range.
This is the assumption I am challenging. I don't think you need this
a
Jason House:
> The in operator does not
> return bool. I think the lack of !in is to encourage writing of efficient
> code. I'm not really sure though.
Lot of time ago I have said I'd like !in, I'm waiting for it still.
Bye,
bearophile
On Fri, 22 May 2009 21:50:03 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 22 May 2009 21:22:55 -0400, Andrei Alexandrescu
wrote:
1. Any range should be seamlessly and efficiently used as an input
range.
This is the assumption I am challenging. I don't think you
Steven Schveighoffer wrote:
On Fri, 22 May 2009 21:22:55 -0400, Andrei Alexandrescu
wrote:
1. Any range should be seamlessly and efficiently used as an input range.
This is the assumption I am challenging. I don't think you need this
assumptions for ranges to work. You can always bolt inpu
Rainer Deyke wrote:
Jason House wrote:
Do you have any common cases where a range would generate nulls as part of
its normal output? I think using the natural null feature of reference
types is a clean and reasonable solution.
Iterating over an array that contains nulls?
Nullable!(T) must b
On Fri, 22 May 2009 21:22:55 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 22 May 2009 17:10:45 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
I'm concentrating mostly on usages with foreach, not algorithms. If
we are to have streams that fit in
Jason House wrote:
> Do you have any common cases where a range would generate nulls as part of
> its normal output? I think using the natural null feature of reference
> types is a clean and reasonable solution.
Iterating over an array that contains nulls?
Nullable!(T) must be able to hold al
Jason House wrote:
BCS wrote:
Hello Jason,
Should the final freezing of D2 be delayed until major D1 libraries
port to D2? I'm mostly thinking of Tango, but I bet there are others.
It may even be good if major libraries could use a Phobos-compatible
license and become part of the releases by
Jason House wrote:
Steven Schveighoffer wrote:
No, you need a pointer. If T is a reference type, how do you distinguish
a null element from the end of the iteration?
Do you have any common cases where a range would generate nulls as part of
its normal output? I think using the natural null
Lionello Lunesu wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
Another idea is to make the T the ref'd arg, similar to how the
system call read() works:
bool popNext(ref T);
This has some benefits:
1) you aren't checking a temporary for emptyness, so it fits well
within a lo
Steven Schveighoffer wrote:
On Fri, 22 May 2009 17:10:45 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
I'm concentrating mostly on usages with foreach, not algorithms. If
we are to have streams that fit into the range model, then they need
to be foreach'able. I don't know
Steven Schveighoffer wrote:
> No, you need a pointer. If T is a reference type, how do you distinguish
> a null element from the end of the iteration?
Do you have any common cases where a range would generate nulls as part of
its normal output? I think using the natural null feature of referen
Robert Clipsham wrote:
> My main thought is that this is a bit early to be thinking about this.
> D2 is still in alpha, with lots of feature and bug changes in each
> release. Until its feature set begins to settle I don't think it is too
> important to think about how to manage a release.
I get
BCS wrote:
> Hello Jason,
>
>> Should the final freezing of D2 be delayed until major D1 libraries
>> port to D2? I'm mostly thinking of Tango, but I bet there are others.
>> It may even be good if major libraries could use a Phobos-compatible
>> license and become part of the releases by digital
Jeremie Pelletier wrote:
> Why is there no !in operator just like there is a !is operator?
> Is it because this expression evaluates to a pointer to the found element?
> Even so, it would make asserts much easier to write.
That is unfortunately a rather sticky point. The in operator does not
re
dsimcha wrote:
> == Quote from Jason House (jason.james.ho...@gmail.com)'s article
>> Andrei has indicated that the current plan is to finalize D2 when his
>> book comes
> out.
>> Given this, I'm interested in what _community_ activity should be done as
>> part
> of this.
>> Should there be a form
On Fri, 22 May 2009 17:10:45 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
I'm concentrating mostly on usages with foreach, not algorithms. If we
are to have streams that fit into the range model, then they need to be
foreach'able. I don't know that they need a lot of su
On Fri, 22 May 2009 20:43:22 -0400, Lionello Lunesu
wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
Another idea is to make the T the ref'd arg, similar to how the system
call read() works:
bool popNext(ref T);
This has some benefits:
1) you aren't checking a temporary fo
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
Another idea is to make the T the ref'd arg, similar to how the system
call read() works:
bool popNext(ref T);
This has some benefits:
1) you aren't checking a temporary for emptyness, so it fits well
within a loop construct
2) you can
Jason House wrote:
Andrei has indicated that the current plan is to finalize D2 when his
book comes out.
Given this, I'm interested in what _community_ activity should be
done as part of this.
Should there be a formal review and polishing of the D spec? More
than just criticizing faults, people
Hello Jason,
Should the final freezing of D2 be delayed until major D1 libraries
port to D2? I'm mostly thinking of Tango, but I bet there are others.
It may even be good if major libraries could use a Phobos-compatible
license and become part of the releases by digital mars.
Maybe it should b
== Quote from Jason House (jason.james.ho...@gmail.com)'s article
> Andrei has indicated that the current plan is to finalize D2 when his book
> comes
out.
> Given this, I'm interested in what _community_ activity should be done as part
of this.
> Should there be a formal review and polishing of t
Why is there no !in operator just like there is a !is operator?
Is it because this expression evaluates to a pointer to the found element? Even
so, it would make asserts much easier to write.
Andrei has indicated that the current plan is to finalize D2 when his book
comes out.
Given this, I'm interested in what _community_ activity should be done as part
of this.
Should there be a formal review and polishing of the D spec? More than just
criticizing faults, people should submit pa
Jason House:
> I'd love to see compile-time functions returning types.<
Glad to see my post appreciated :-)
>IMHO, it's far superior to the template-based approach.<
Even if such compile-time functions can't fully replace templates (so templates
can't be removed from the language) such functio
bearophile Wrote:
> bearophile:
> > Having a return also helps to see templates as closer to compile-time
> > functions (changing few things there may be ways to merge the syntax of
> > templates with the syntax of compile time functions, reducing the
> > complexity of D).<
>
> To write some t
Steven Schveighoffer wrote:
I'm concentrating mostly on usages with foreach, not algorithms. If we
are to have streams that fit into the range model, then they need to be
foreach'able. I don't know that they need a lot of support to feed into
std.algorithm as reference data. I.e. you aren't
On Fri, 22 May 2009 15:55:52 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
I'm not convinced that range is the best fit for ref'd data anyways,
opApply is much more adept at it.
If ranges aren't fit to mutate stuff, we failed. Many algorithms in
std.algorithm mutate th
On Fri, 22 May 2009 16:40:55 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
ref accomplishes all of this, except you can't get at the underlying
pointer to do things like compare to null or rebind. Maybe we simply
need some new operators to get at the ref addresses.
Defi
Steven Schveighoffer wrote:
ref accomplishes all of this, except you can't get at the underlying
pointer to do things like compare to null or rebind. Maybe we simply
need some new operators to get at the ref addresses.
Defining null references has been on the table too. I wrote a paragraph
a
On Fri, 22 May 2009 15:55:52 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
Another idea is to make the T the ref'd arg, similar to how the system
call read() works:
bool popNext(ref T);
This has some benefits:
1) you aren't checking a temporary for emptyness, so it fits
"bearophile" wrote in message
news:gv6e4p$1m3...@digitalmars.com...
> bearophile:
>> Having a return also helps to see templates as closer to compile-time
>> functions (changing few things there may be ways to merge the syntax of
>> templates with the syntax of compile time functions, reducing
Steven Schveighoffer wrote:
Another idea is to make the T the ref'd arg, similar to how the system
call read() works:
bool popNext(ref T);
This has some benefits:
1) you aren't checking a temporary for emptyness, so it fits well within
a loop construct
2) you can avoid returning a dummy ele
On Fri, 22 May 2009 11:48:34 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
The thread discussing what to do for input ranges vs. forward ranges
got me thinking.
The range concept may be defined backwards in terms of which is more
specialized. Consider that an input rang
Steven Schveighoffer wrote:
[snip]
In addition, without a buffer to worry about, the code becomes much
simpler.
I agree.
Andrei
On Fri, 22 May 2009 11:48:34 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
And finally, if you copy such a range, the buffer might be copied while
the stream itself may not. this could result in strange garbage data.
I don't understand this. You could make sure copy does
Steve Teale wrote:
Andrei Alexandrescu Wrote:
I don't quite understand this. Ranges are a very simple abstraction
for iteration. They show how other iteration abstractions either
were too unsafe and verbose (C++/STL) or too bare-bones (C#
iterators, Java iterators, singly-linked lists used by f
Jarrett Billingsley Wrote:
> On Thu, May 21, 2009 at 10:01 AM, Steve Teale
> wrote:
> > Is this error intentional
> > strange.d(10): Error: template strange.A.opCall(T) conflicts with function
> > strange.A.opCall at strange.d(8)
> >
> > You can make it work with the template version of opCall w
Andrei Alexandrescu Wrote:
> I don't quite understand this. Ranges are a very simple abstraction for
> iteration. They show how other iteration abstractions either were too
> unsafe and verbose (C++/STL) or too bare-bones (C# iterators, Java
> iterators, singly-linked lists used by functional l
nobody, you can see how the GC interacts with your code also with the following
small D1 program:
import std.c.stdlib: malloc;
struct S { int i; }
void main() {
const N = 20_000_000;
static if (true) // change this to false
S** sa = cast(S**)calloc(N, (S*).sizeof);
else
bearophile:
>To write some templates as compile-time functions you may need to add a new
>type to D, named "type":<
To see if the idea of compile-time functions that process compile-time
variables of type "type" isn't fully crazy I have translated some of the D1
templates of my dlibs into such
Steven Schveighoffer wrote:
The thread discussing what to do for input ranges vs. forward ranges got
me thinking.
The range concept may be defined backwards in terms of which is more
specialized. Consider that an input range is always usable as a
stream. But a stream is not easy to use as
bearophile:
> Having a return also helps to see templates as closer to compile-time
> functions (changing few things there may be ways to merge the syntax of
> templates with the syntax of compile time functions, reducing the complexity
> of D).<
To write some templates as compile-time function
A configurable syntax has some advantages:
- It makes the language more flexible. I like the idea of this a lot.
- allows to do things that are otherwise hard to do.
- It can be used to write shorter programs.
- It can be used to define a sub-language fitter for a specific job. (Ruby
shows some of
Andrei Alexandrescu:
> 1. Allow inner name promotion even if the template defines other
> members, as long as they are all private:
>
> now:
>
> template WidgetImpl(A, B) {
> ...
> alias ... Result;
> }
>
> template Widget(A, B) {
> alias WidgetImpl!(A, B) Widget;
> }
>
> proposed:
Georg Wrede wrote:
Jason House wrote:
Georg Wrede Wrote:
--- Disclaimer: this is a bit long. Read it later. ---
Wow, you're right. Sadly, I stopped reading about 80% through
(discussion on D4)
Yeah, one should not write opinion pieces when inspired...
At a high level, I agree with you
Jason House wrote:
I wonder if a compiler patch to loosen the restrictions would be accepted.
Something like what you tried should be trivial to support.
I doubt it's trivial to support... depending on when it's evaluated the
version may or may not be set when it's checked, which is likely to
Jason House wrote:
Georg Wrede Wrote:
--- Disclaimer: this is a bit long. Read it later. ---
Wow, you're right. Sadly, I stopped reading about 80% through
(discussion on D4)
Yeah, one should not write opinion pieces when inspired...
At a high level, I agree with your assessment about a
Robert Clipsham Wrote:
> I recently came across this:
>
> version( BackendFoo ) {}
> else version( BackendBar ) {}
> else version( BackendCar ) {}
> else
> {
>pragma( msg, "Warning: backend version undefined" );
>pragma( msg, "Attempting to guess backend" );
>version( Windows )
>{
Georg Wrede Wrote:
>
> --- Disclaimer: this is a bit long. Read it later. ---
Wow, you're right. Sadly, I stopped reading about 80% through (discussion on D4)
At a high level, I agree with your assessment about an easy growth path for
newbors to gurus. I should also add that a language must ma
Tim Matthews wrote:
From what can I see you have a few different posssible versions but
when no version is defined you can select a default version based on
other stuff like windows operating system. Rather than modify the
versions or add aditional to match the system you can create complex
'
On Fri, 22 May 2009 20:29:03 +1200, Robert Clipsham
wrote:
Tim Matthews wrote:
I think this would be less ugly:
template vers(char[] V)
{
mixin("version(" ~ V ~ ")
{
const bool vers = true;
}
else
{
const bool vers = false;
}");
}
static
Robert Clipsham wrote:
I recently came across this:
version( BackendFoo ) {}
else version( BackendBar ) {}
else version( BackendCar ) {}
else
{
pragma( msg, "Warning: backend version undefined" );
pragma( msg, "Attempting to guess backend" );
version( Windows )
{
version = BackendFoo
Tim Matthews wrote:
I think this would be less ugly:
template vers(char[] V)
{
mixin("version(" ~ V ~ ")
{
const bool vers = true;
}
else
{
const bool vers = false;
}");
}
static if(vers!("BackendFoo") || vers!("Windows"))
{
//
}
else s
Hello Rainer,
My favorite deployment system is the application bundle under OS X.
It's a directory that looks like a file. Beneath the covers it has
frameworks and configuration files and multiple executables and all
that
crap, but to the user, it looks like a single file. You can copy it,
ren
64 matches
Mail list logo
