Andrei Alexandrescu wrote:
> dsimcha wrote:
>> Please, please, please PLEASE, PRETTY PLEASE FOR THE LOVE OF GOD
>> ALMIGHTY tell me
>> you're not serious!!! Isn't changing the interface such that forward
>> ranges are
>> no longer effectively a subtype of input ranges a bit drastic? Or do
>> you
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Apparently the entire talk has been filmed, and the conference
organizers have edited the footage a bit and will make it available
soon. Stay tuned.
Andrei
Why do you taunt us so?
"Coming soon: something awesome you want to see but can't yet. J
Andrei Alexandrescu wrote:
> Apparently the entire talk has been filmed, and the conference
> organizers have edited the footage a bit and will make it available
> soon. Stay tuned.
>
> Andrei
Why do you taunt us so?
"Coming soon: something awesome you want to see but can't yet. Just
remindin
Apparently the entire talk has been filmed, and the conference
organizers have edited the footage a bit and will make it available
soon. Stay tuned.
Andrei
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:gv2hj8$k1...@digitalmars.com...
dsimcha wrote:
Consider:
struct R
{
bool empty();
ref int front();
void popFront();
}
ref int popNext(ref R fwdRange)
{
auto result = & fwdRange.front();
fwdRange.popFront;
Andrei Alexandrescu wrote:
struct R
{
bool empty();
ref int front();
void popFront();
}
ref int popNext(ref R fwdRange)
{
auto result = & fwdRange.front();
fwdRange.popFront;
return *result;
}
void main()
{
R r;
int x = r.popNext;
}
This should work, I just noti
Nick Sabalausky wrote:
> ...
>
> Maybe this is naive, but what about an AST-level template/generic? Couldn't
> that provide for the best of both worlds?
>
> For instance, suppose (purely hypothetically) that the .NET assembly system
> were changed to allow the source for a D/C++ style of sour
"Andrei Alexandrescu" wrote in message
news:gv2hj8$k1...@digitalmars.com...
> dsimcha wrote:
>
> Consider:
>
> struct R
> {
> bool empty();
> ref int front();
> void popFront();
> }
>
> ref int popNext(ref R fwdRange)
> {
> auto result = & fwdRange.front();
> fwdRange.popFront
"Bill Baxter" wrote in message
news:mailman.151.1242855932.13405.digitalmar...@puremagic.com...
> On Wed, May 20, 2009 at 1:09 PM, Andrei Alexandrescu
> wrote:
>> Yigal Chripun wrote:
>>>
>>> I think you miss the point here.
>>> Generics and code generation are two separate and orthogonal featur
"Christopher Wright" wrote in message
news:gv29vn$7a...@digitalmars.com...
> Nick Sabalausky wrote:
>> "Christopher Wright" wrote in message
>> news:gv0p4e$uv...@digitalmars.com...
>>> Nick Sabalausky wrote:
I can see certain potential benefits to the general way C# does
generics, bu
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
MLT wrote:
One needs something like a lazy semi-infinite range, that only calls
a certain function when it reaches an unexplored part.
That's a great abstraction, but we can't afford to impose that to
ev
dsimcha wrote:
Please, please, please PLEASE, PRETTY PLEASE FOR THE LOVE OF GOD ALMIGHTY tell
me
you're not serious!!! Isn't changing the interface such that forward ranges are
no longer effectively a subtype of input ranges a bit drastic? Or do you have
some magic up your sleeve that, given a
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> MLT wrote:
> > One needs something like a lazy semi-infinite range, that only calls
> > a certain function when it reaches an unexplored part.
> That's a great abstraction, but we can't afford to impose that to
> everybod
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> MLT wrote:
> > One needs something like a lazy semi-infinite range, that only calls
> > a certain function when it reaches an unexplored part.
> That's a great abstraction, but we can't afford to impose that to
> everybod
MLT wrote:
One needs something like a lazy semi-infinite range, that only calls
a certain function when it reaches an unexplored part.
That's a great abstraction, but we can't afford to impose that to
everybody. There must be an abstraction for a one-pass go through an
arbitrarily long stream
Andrei Alexandrescu Wrote:
> MLT wrote:
> > I think that if
> >> R last = r;
> > then after
> >> r.popFront;
> > the order of elements in "last" should not change, no matter what
> > type of range you are dealing with. (That means that input operations
> > would be buffered to the leftmost range t
Nick Sabalausky wrote:
"Christopher Wright" wrote in message
news:gv0p4e$uv...@digitalmars.com...
Nick Sabalausky wrote:
I can see certain potential benefits to the general way C# does generics,
but until the old (and I do mean old) issue of "There's an IComparable,
so why the hell won't MS g
On Wed, May 20, 2009 at 5:11 PM, Jason House
wrote:
> Bill Baxter Wrote:
>
>> On Wed, May 20, 2009 at 4:03 PM, dsimcha wrote:
>> > == Quote from Jason House (jason.james.ho...@gmail.com)'s article
>> >> IMHO, D should have a type with low size and function call overhead >
>> >> like a
>> > struc
== Quote from Jason House (jason.james.ho...@gmail.com)'s article
> dsimcha Wrote:
> > == Quote from Jason House (jason.james.ho...@gmail.com)'s article
> > > IMHO, D should have a type with low size and function call overhead >
> > > like a
> > struct as well as reference semantics like a class.
Andrei Alexandrescu Wrote:
> MLT wrote:
> > I think that if
> >> R last = r;
> > then after
> >> r.popFront;
> > the order of elements in "last" should not change, no matter what
> > type of range you are dealing with. (That means that input operations
> > would be buffered to the leftmost range t
Bill Baxter Wrote:
> On Wed, May 20, 2009 at 4:03 PM, dsimcha wrote:
> > == Quote from Jason House (jason.james.ho...@gmail.com)'s article
> >> IMHO, D should have a type with low size and function call overhead > like
> >> a
> > struct as well as reference semantics like a class.
> >
> > What's
dsimcha Wrote:
> == Quote from Jason House (jason.james.ho...@gmail.com)'s article
> > IMHO, D should have a type with low size and function call overhead > like a
> struct as well as reference semantics like a class.
>
> What's wrong with a pointer to a heap-allocated struct? I sometimes need
MLT wrote:
I think that if
R last = r;
then after
r.popFront;
the order of elements in "last" should not change, no matter what
type of range you are dealing with. (That means that input operations
would be buffered to the leftmost range that still extsts.)
If I understood the logic of range
Andrei Alexandrescu wrote:
...
>
> So we're looking at a number of problems here. One is that we'd need to
> change the language in several places to accommodate an ill-conceived
> feature. Another is that I can't seem to get some very simple points
> across such as the difference between a to
On Wed, May 20, 2009 at 4:03 PM, dsimcha wrote:
> == Quote from Jason House (jason.james.ho...@gmail.com)'s article
>> IMHO, D should have a type with low size and function call overhead > like a
> struct as well as reference semantics like a class.
>
> What's wrong with a pointer to a heap-alloca
== Quote from Jason House (jason.james.ho...@gmail.com)'s article
> IMHO, D should have a type with low size and function call overhead > like a
struct as well as reference semantics like a class.
What's wrong with a pointer to a heap-allocated struct? I sometimes need what
you
describe, too, an
On Wed, 20 May 2009 13:35:14 -0400, Andrei Alexandrescu
wrote:
Jason House wrote:
I feel like there are too many differences between input and forward
ranges for such a minor difference. Many range functions are written
assuming no side effects on the caller. This can restrict the use of
hel
Andrei Alexandrescu Wrote:
> In wake of a few discussion I've witnessed, I'm thinking of a last
> change for ranges. (In fact there's one more, but that's minor.)
>
> The problem is that input ranges and forward ranges have the same
> syntactic interface, but different semantic interfaces. Cons
Bill Baxter Wrote:
> On Wed, May 20, 2009 at 12:05 PM, dsimcha wrote:
> > == Quote from Bill Baxter (wbax...@gmail.com)'s article
> >> On Wed, May 20, 2009 at 11:44 AM, Andrei Alexandrescu
> >> wrote:
> >> > Jason House wrote:
> >> >>
> >> >> Andrei Alexandrescu Wrote:
> >> >>
> >> >>> Jason Hou
On Wed, May 20, 2009 at 1:09 PM, Andrei Alexandrescu
wrote:
> Yigal Chripun wrote:
>>
>> I think you miss the point here.
>> Generics and code generation are two separate and orthogonal features that
>> where conflated together by C++.
>
> It's kind of odd, then, that for example the Generative Pr
dsimcha Wrote:
> == Quote from Bill Baxter (wbax...@gmail.com)'s article
> > On Wed, May 20, 2009 at 11:44 AM, Andrei Alexandrescu
> > wrote:
> > > Jason House wrote:
> > >>
> > >> Andrei Alexandrescu Wrote:
> > >>
> > >>> Jason House wrote:
> >
> > I feel like there are too many differ
Reply to Yigal,
D templates provide mostly cosmetic changes to this.
If you think D's templates are C++'s template with a few "cosmetic changes"
than you aren't paying attention.
A few cosmetic changes aren't going to allow 1.4MB of c++ header files to
be anywhere near duplicated in 2000
Reply to Yigal,
BCS wrote:
minor point; I said you have to give the compiler all the source
files. You might not actually nned to compile them all, but without
some external meta data, it still needs to be handled the full
because it can't find them on it's own. And at that point you might
as
dsimcha wrote:
== Quote from Ary Borenszweig (a...@esperanto.org.ar)'s article
dsimcha escribió:
== Quote from Christopher Wright (dhase...@gmail.com)'s article
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:gus0lu$1sm...@digitalmars.com...
I've repeatedly failed to fig
dsimcha wrote:
Not sure I agree. C++ templates were probably intended to be something like
generics initially and became Turing-complete almost by accident.
That is factually correct. It was quite a hubbub on the C++
standardization committee when Erwin Unruh wrote a C++ program that
wrote p
On Wed, 20 May 2009 21:02:02 +0300, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
Bicycle shed: Well, since output ranges use 'put', how about 'get' for
input ranges?
Nice color :o). In fact, "put" is a poor choice because it doesn't
reflect advancement. Probably putNext and getNext
== Quote from Yigal Chripun (yigal...@gmail.com)'s article
> Andrei Alexandrescu wrote:
> > Lutger wrote:
> >> Andrei Alexandrescu wrote:
> >>
> >> ...
> What the heck do you need generics for when you have real
> templates? To me,
> generics seem like just a lame excuse for templat
Yigal Chripun wrote:
I think you miss the point here.
Generics and code generation are two separate and orthogonal features
that where conflated together by C++.
It's kind of odd, then, that for example the Generative Programming book
(http://www.generative-programming.org) chose to treat the
Andrei Alexandrescu wrote:
Lutger wrote:
Andrei Alexandrescu wrote:
...
What the heck do you need generics for when you have real
templates? To me,
generics seem like just a lame excuse for templates.
I agree. Then, templates aren't easy to implement and they were
understandably already bus
On Wed, May 20, 2009 at 12:05 PM, dsimcha wrote:
> == Quote from Bill Baxter (wbax...@gmail.com)'s article
>> On Wed, May 20, 2009 at 11:44 AM, Andrei Alexandrescu
>> wrote:
>> > Jason House wrote:
>> >>
>> >> Andrei Alexandrescu Wrote:
>> >>
>> >>> Jason House wrote:
>>
>> I feel like
BCS wrote:
> minor point; I said you have to give the compiler all the source files.
You might not actually nned to compile them all, but without some
external meta data, it still needs to be handled the full because it
can't find them on it's own. And at that point you might as well compile
"Christopher Wright" wrote in message
news:gv0p4e$uv...@digitalmars.com...
> Nick Sabalausky wrote:
>> I can see certain potential benefits to the general way C# does generics,
>> but until the old (and I do mean old) issue of "There's an IComparable,
>> so why the hell won't MS give us an IAri
On Wed, 20 May 2009 14:02:02 -0400, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
Bicycle shed: Well, since output ranges use 'put', how about 'get' for
input ranges?
Nice color :o). In fact, "put" is a poor choice because it doesn't
reflect advancement. Probably putNext and getNext
== Quote from Bill Baxter (wbax...@gmail.com)'s article
> On Wed, May 20, 2009 at 11:44 AM, Andrei Alexandrescu
> wrote:
> > Jason House wrote:
> >>
> >> Andrei Alexandrescu Wrote:
> >>
> >>> Jason House wrote:
>
> I feel like there are too many differences between input and forward
> >>
== Quote from Bill Baxter (wbax...@gmail.com)'s article
> On Wed, May 20, 2009 at 11:44 AM, Andrei Alexandrescu
> wrote:
> > Jason House wrote:
> >>
> >> Andrei Alexandrescu Wrote:
> >>
> >>> Jason House wrote:
>
> I feel like there are too many differences between input and forward
> >>
On Wed, May 20, 2009 at 11:44 AM, Andrei Alexandrescu
wrote:
> Jason House wrote:
>>
>> Andrei Alexandrescu Wrote:
>>
>>> Jason House wrote:
I feel like there are too many differences between input and forward
ranges for such a minor difference. Many range functions are written
== Quote from Jason House (jason.james.ho...@gmail.com)'s article
> Andrei Alexandrescu Wrote:
> > Jason House wrote:
> > > I feel like there are too many differences between input and forward
> > > ranges for such a minor difference. Many range functions are written
> > > assuming no side effects
Jason House wrote:
Andrei Alexandrescu Wrote:
Jason House wrote:
I feel like there are too many differences between input and forward
ranges for such a minor difference. Many range functions are written
assuming no side effects on the caller. This can restrict the use of
helper functions. It m
Andrei Alexandrescu Wrote:
> Jason House wrote:
> > I feel like there are too many differences between input and forward
> > ranges for such a minor difference. Many range functions are written
> > assuming no side effects on the caller. This can restrict the use of
> > helper functions. It may be
Robert Fraser wrote:
dsimcha wrote:
Also, while we're fine tuning input
ranges vs. forward ranges, I think the concept of iterables as a
catch-all for
ranges, opApply, builtins, etc. needs to be introduced and fine tuned,
too. We've
shown on this NG previously that, while ranges are usually p
dsimcha wrote:
Also, while we're fine tuning input
ranges vs. forward ranges, I think the concept of iterables as a catch-all for
ranges, opApply, builtins, etc. needs to be introduced and fine tuned, too.
We've
shown on this NG previously that, while ranges are usually preferable for the
flexi
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> In wake of a few discussion I've witnessed, I'm thinking of a last
> change for ranges. (In fact there's one more, but that's minor.)
> The problem is that input ranges and forward ranges have the same
> syntactic interfa
Robert Jacques wrote:
Bicycle shed: Well, since output ranges use 'put', how about 'get' for
input ranges?
Nice color :o). In fact, "put" is a poor choice because it doesn't
reflect advancement. Probably putNext and getNext are better.
Andrei
On Wed, 20 May 2009 13:04:42 -0400, Andrei Alexandrescu
wrote:
Bill Baxter wrote:
On Wed, May 20, 2009 at 9:19 AM, Andrei Alexandrescu
wrote:
I'm thinking a better design is to require any range that's forward or
better to define a function save(). Ranges that don't implement it are
input
Jason House wrote:
I feel like there are too many differences between input and forward
ranges for such a minor difference. Many range functions are written
assuming no side effects on the caller. This can restrict the use of
helper functions. It may be best to make their usage different...
So
I feel like there are too many differences between input and forward ranges for
such a minor difference. Many range functions are written assuming no side
effects on the caller. This can restrict the use of helper functions. It may be
best to make their usage different...
Andrei Alexandrescu W
Bill Baxter wrote:
On Wed, May 20, 2009 at 9:19 AM, Andrei Alexandrescu
wrote:
I'm thinking a better design is to require any range that's forward or
better to define a function save(). Ranges that don't implement it are input
ranges; those that do, will guarantee a brand new range is returned
dsimcha wrote:
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
Why not r.dup?
.dup is supposed to imply copying of the range's contents, not copying of the
range's iteration state.
Yes, for arrays save() is:
T[] save(T)(T[] r) { return r; }
Andrei
On Wed, May 20, 2009 at 9:19 AM, Andrei Alexandrescu
wrote:
> I'm thinking a better design is to require any range that's forward or
> better to define a function save(). Ranges that don't implement it are input
> ranges; those that do, will guarantee a brand new range is returned from
> save().
Andrei Alexandrescu wrote:
In wake of a few discussion I've witnessed, I'm thinking of a last
change for ranges. (In fact there's one more, but that's minor.)
The problem is that input ranges and forward ranges have the same
syntactic interface, but different semantic interfaces. Consider the
Kagamin wrote:
Frits van Bommel Wrote:
That's the difference. You can't fold templates because they're binary
incompatible as opposite to generics.
They're not always binary-incompatible. For instance, if a template only works
with pointers or references (this includes object references) to p
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
> Why not r.dup?
.dup is supposed to imply copying of the range's contents, not copying of the
range's iteration state.
On Wed, 20 May 2009 20:23:27 +0400, Denis Koroskin <2kor...@gmail.com> wrote:
> On Wed, 20 May 2009 20:19:30 +0400, Andrei Alexandrescu
> wrote:
>
>> In wake of a few discussion I've witnessed, I'm thinking of a last
>> change for ranges. (In fact there's one more, but that's minor.)
>>
>> The
On Wed, 20 May 2009 20:19:30 +0400, Andrei Alexandrescu
wrote:
> In wake of a few discussion I've witnessed, I'm thinking of a last
> change for ranges. (In fact there's one more, but that's minor.)
>
> The problem is that input ranges and forward ranges have the same
> syntactic interface,
In wake of a few discussion I've witnessed, I'm thinking of a last
change for ranges. (In fact there's one more, but that's minor.)
The problem is that input ranges and forward ranges have the same
syntactic interface, but different semantic interfaces. Consider the
problem of finding the firs
KennyTM~ wrote:
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
wrote:
It's an awful idea. It's a non-idea. If "idea" had an antonym, that
would be it.
I can't fathom what's on the mind of a person (not you, at least you
foresee so
Frits van Bommel Wrote:
> > That's the difference. You can't fold templates because they're binary
> > incompatible as opposite to generics.
>
> They're not always binary-incompatible. For instance, if a template only
> works
> with pointers or references (this includes object references) to p
Jason House wrote:
bearophile Wrote:
Andrei Alexandrescu:
I don't plan to discuss minor features on this group anymore.
That's a real pity.
I had a lot of respect for you and your perpetual inclusion of the D
community (both announcing features and getting design feedback).
Very early on in
Bill Baxter wrote:
On Wed, May 20, 2009 at 7:28 AM, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
wrote:
It's an awful idea. It's a non-idea. If "idea" had an antonym, that
would be it.
I can't fathom what's on the mind of a perso
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
wrote:
It's an awful idea. It's a non-idea. If "idea" had an antonym, that
would be it.
I can't fathom what's on the mind of a person (not you, at least you
foresee some potential prob
On Wed, May 20, 2009 at 7:28 AM, Andrei Alexandrescu
wrote:
> Denis Koroskin wrote:
>>
>> On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
>> wrote:
>>
>>> It's an awful idea. It's a non-idea. If "idea" had an antonym, that
>>> would be it.
>>>
>>> I can't fathom what's on the mind of a p
Denis Koroskin:
> It also gracefully solves an issue with uniform distribution
> uniform(0..int.max) - exclusive
> uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)
To avoid the possible confusion caused by ... Chapel uses ..#
uniform(0 .. int.max) - exclusive
uniform(0 ..#
Ary Borenszweig wrote:
This is easily solved by making the lexer not allow the "" token, or
"." token, etc. (maximum 3 dots.) This way you are forced to
insert a space there to make your intention clear, and you can never
have bugs like that.
I agree that things could be fixed. This
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
wrote:
It's an awful idea. It's a non-idea. If "idea" had an antonym, that
would be it.
I can't fathom what's on the mind of a person (not you, at least you
foresee some potential prob
Denis Koroskin wrote:
On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
wrote:
It's an awful idea. It's a non-idea. If "idea" had an antonym, that
would be it.
I can't fathom what's on the mind of a person (not you, at least you
foresee some potential problems) who, even after patien
Lutger wrote:
Andrei Alexandrescu wrote:
...
What the heck do you need generics for when you have real templates? To me,
generics seem like just a lame excuse for templates.
I agree. Then, templates aren't easy to implement and they were
understandably already busy implementing the using stat
bearophile Wrote:
Andrei Alexandrescu:
> I don't plan to discuss minor features on this group anymore.
That's a real pity.
I had a lot of respect for you and your perpetual inclusion of the D community
(both announcing features and getting design feedback).
Very early on in this thread, it be
== Quote from Ary Borenszweig (a...@esperanto.org.ar)'s article
> dsimcha escribió:
> > == Quote from Christopher Wright (dhase...@gmail.com)'s article
> >> Nick Sabalausky wrote:
> >>> "Andrei Alexandrescu" wrote in message
> >>> news:gus0lu$1sm...@digitalmars.com...
> >>>
> I've repeatedly
Tim Matthews Wrote:
> On Wed, 20 May 2009 15:01:44 +1200, Jeremie Pelletier
> wrote:
>
>
> > I think it is so the parser knows how to make the difference between the
> > template symbol and an instance symbol.
> >
>
>
> Can you explain a bit more on this? function templates dont require t
bearophile wrote:
Christopher Wright:
The more common suggestion is:
alias bar = foo;
I can add this too:
typedef Bar = Foo;
This changes in typedef and alias can solve two of the small problems I have
with D. Let's see if Walter accepts such ideas.
(In the last days two more ideas have flo
On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
wrote:
> It's an awful idea. It's a non-idea. If "idea" had an antonym, that
> would be it.
>
> I can't fathom what's on the mind of a person (not you, at least you
> foresee some potential problems) who, even after patiently explained th
Andrei Alexandrescu wrote:
Robert Fraser wrote:
Frank Benoit wrote:
Alexander Pánek schrieb:
Andrei Alexandrescu wrote:
bearophile wrote:
Andrei Alexandrescu:
Thank you for bringing a "real" example that gives something to
work on.
Awful!<
Well, one of your cases was wrong. Using the +
bearophile wrote:
Frits van Bommel:
To do the latter transformation, the pass would need to be reimplemented to run
when the code is closer to machine code.
Can't this feature be asked to the LLVM developers?
Sure, feel free to file a feature request:
http://llvm.org/bugs/enter_bug.cgi?prod
dsimcha wrote:
== Quote from Christopher Wright (dhase...@gmail.com)'s article
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:gus0lu$1sm...@digitalmars.com...
I've repeatedly failed to figure out the coolness of C#, and would
appreciate a few pointers. Or references. Or d
Frits van Bommel:
> To do the latter transformation, the pass would need to be reimplemented to
> run
> when the code is closer to machine code.
Can't this feature be asked to the LLVM developers?
Bye,
bearophile
Nick Sabalausky wrote:
I can see certain potential benefits to the general way C# does generics,
but until the old (and I do mean old) issue of "There's an IComparable, so
why the hell won't MS give us an IArithmetic so we can actually use
arithmetic operators on generic code?" gets fixed (and
Ary Borenszweig:
> That's why generics doesn't suck: if there's something wrong in them,
> the compiler tells you in compile-time. In D, you get the errors only
> when instantiating that template.
It's just like in dynamic languages, you need to unittest them a lot :-)
So having a "static throws
dsimcha escribió:
== Quote from Christopher Wright (dhase...@gmail.com)'s article
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:gus0lu$1sm...@digitalmars.com...
I've repeatedly failed to figure out the coolness of C#, and would
appreciate a few pointers. Or references. O
On Wed, 20 May 2009 15:01:44 +1200, Jeremie Pelletier
wrote:
I think it is so the parser knows how to make the difference between the
template symbol and an instance symbol.
Can you explain a bit more on this? function templates dont require this
by the way and I didn't think a templ
Denis Koroskin wrote:
On Wed, 20 May 2009 13:09:37 +0400, Kagamin wrote:
BCS Wrote:
smaller object code? OTOH a good implementation will noice when I can
fold
together several template expansions
That's the difference. You can't fold templates because they're binary
incompatible as oppos
"Lutger" wrote in message
news:gv090o$22...@digitalmars.com...
> Andrei Alexandrescu wrote:
>
> ...
>>> What the heck do you need generics for when you have real templates? To
>>> me,
>>> generics seem like just a lame excuse for templates.
>>
>> I agree. Then, templates aren't easy to implemen
Walter Bright:
Sorry for raising this thread.
While C# has purposes somewhat different from D, I think C# designers are right
in their emphasys on safety. Modern programmers appreciate some safeties, and
modern languages give them. The ideas I am talking about are already
implemented in C#.
D c
On Wed, 20 May 2009 13:09:37 +0400, Kagamin wrote:
> BCS Wrote:
>
>> smaller object code? OTOH a good implementation will noice when I can
>> fold
>> together several template expansions
>
> That's the difference. You can't fold templates because they're binary
> incompatible as opposite to g
Kagamin wrote:
BCS Wrote:
smaller object code? OTOH a good implementation will noice when I can fold
together several template expansions
That's the difference. You can't fold templates because they're binary
incompatible as opposite to generics.
They're not always binary-incompatible. For
BCS Wrote:
> smaller object code? OTOH a good implementation will noice when I can fold
> together several template expansions
That's the difference. You can't fold templates because they're binary
incompatible as opposite to generics.
Christopher Wright:
> The more common suggestion is:
> alias bar = foo;
I can add this too:
typedef Bar = Foo;
This changes in typedef and alias can solve two of the small problems I have
with D. Let's see if Walter accepts such ideas.
(In the last days two more ideas have floated in this newsg
Nick Sabalausky wrote:
"Nick Sabalausky" wrote in message
news:guscm2$2jf...@digitalmars.com...
"Don" wrote in message
news:gurkuo$17n...@digitalmars.com...
Nick Sabalausky wrote:
"Don" wrote in message
news:gur1ec$18...@digitalmars.com...
If warnings exist, libraries must not do anything t
heh: http://d.puremagic.com/issues/show_bug.cgi?id=596
Why can we do
string s;
switch(s)
{
case "blah":
break;
default:
}
but not
byte[] a;
switch(a)
{
case [cast(byte)1,2,3]:
break;
default:
}
?
On Wed, 20 May 2009 17:31:14 +1200, Jarrett Billingsley
wrote:
Just, uh, wow. Please dude, read up on this stuff first.
This thread turned into a java vs .net argument. I'm sorry but I don't
know the details of the JVM's just in time compiler. The virtual machine
in the name plus the
1 - 100 of 103 matches
Mail list logo
