Justin Johansson wrote:
6. There must be many things I forgot to mention, or that cause grief
to many of us. Please add to/comment on this list.
Sorry I'm not familiar with any prior discussion on this or even where
it's at (basically I'm in D1 world), but what about
constructors for struc
Gzp wrote:
bearophile wrote:
Andrei Alexandrescu:
* Encode operators by compile-time strings. For example, instead of
the plethora of opAdd, opMul, ..., we'd have this:
T opBinary(string op)(T rhs) { ... }
The string is "+", "*", etc.
Can you show an example of defining an operator, like
Wed, 18 Nov 2009 18:35:18 -0800, Andrei Alexandrescu wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> The rewrite is done long after lexing, so no low-level problems there.
>>
>> Oh, I thought it would let you introduce new operators. But it's only
>> about the existing ones.
>>
>> I f
Lars T. Kyllingstad wrote:
Justin Johansson wrote:
6. There must be many things I forgot to mention, or that cause grief
to many of us. Please add to/comment on this list.
Sorry I'm not familiar with any prior discussion on this or even where
it's at (basically I'm in D1 world), but what ab
retard wrote:
Does the new system allow overriding only some binary operations and not
all of them at once?
struct S {
S opBinary( string op )( S rhs ) if ( op == "+" ) {
// Do stuff
}
}
I thought generic member functions were non-virtual?
Andrei Alexandrescu wrote:
3. T
Wed, 18 Nov 2009 18:38:25 -0500, Robert Jacques wrote:
> On Wed, 18 Nov 2009 15:01:10 -0500, Stewart Gordon
> wrote:
>
>> Robert Jacques wrote:
>>
>>> However, I imagine tuple(a++,b++) would have some overhead, which is
>>> exactly what someone is trying to avoid by using custom for loops.
>>
Thu, 19 Nov 2009 00:00:00 +0200, Yigal Chripun wrote:
> Ellery Newcomer wrote:
> foo(a, b) is identical to foo(t);
>>
>> does ML have any equivalent of template parameters? eg
>>
>> foo!(1,int);
> foo's signature is actually: `a -> `a which is like doing in D: T foo(T)
> (T n) { return n + n;
Thu, 19 Nov 2009 09:33:07 +0100, Simen kjaeraas wrote:
> retard wrote:
>
>> Does the new system allow overriding only some binary operations and
>> not all of them at once?
>
> struct S {
> S opBinary( string op )( S rhs ) if ( op == "+" ) {
> // Do stuff
> }
> }
>
>> I thou
Andrei Alexandrescu wrote:
We're entering the finale of D2 and I want to keep a short list of
things that must be done and integrated in the release. It is clearly
understood by all of us that there are many things that could and
probably should be done.
1. Currently Walter and Don are dilige
On Thu, 19 Nov 2009 11:53:51 +0300, Don wrote:
Andrei Alexandrescu wrote:
We're entering the finale of D2 and I want to keep a short list of
things that must be done and integrated in the release. It is clearly
understood by all of us that there are many things that could and
probably sho
retard Wrote:
> Thu, 19 Nov 2009 00:00:00 +0200, Yigal Chripun wrote:
>
> > Ellery Newcomer wrote:
> > foo(a, b) is identical to foo(t);
> >>
> >> does ML have any equivalent of template parameters? eg
> >>
> >> foo!(1,int);
>
> > foo's signature is actually: `a -> `a which is like doing in
Yes; opBinary was just given as an example. Unary operators look like this:
T opUnary(string op)();
(And maybe trinary operators ?: ) :)
Can they still be overloaded ? Will they have a similar syntax ? If so
what about the e++ and ++e operators? How they are distinct ? Or is
the latter elimi
Don wrote:
Andrei Alexandrescu wrote:
We're entering the finale of D2 and I want to keep a short list of
things that must be done and integrated in the release. It is clearly
understood by all of us that there are many things that could and
probably should be done.
1. Currently Walter and Do
Andrei Alexandrescu wrote:
We're entering the finale of D2 and I want to keep a short list of
things that must be done and integrated in the release. It is clearly
understood by all of us that there are many things that could and
probably should be done.
1. Currently Walter and Don are dilige
Denis Koroskin wrote:
On Thu, 19 Nov 2009 11:53:51 +0300, Don wrote:
Andrei Alexandrescu wrote:
We're entering the finale of D2 and I want to keep a short list of
things that must be done and integrated in the release. It is clearly
understood by all of us that there are many things that cou
Thu, 19 Nov 2009 04:11:30 -0500, yigal chripun wrote:
> retard Wrote:
>
>> Thu, 19 Nov 2009 00:00:00 +0200, Yigal Chripun wrote:
>>
>> > Ellery Newcomer wrote:
>> > foo(a, b) is identical to foo(t);
>> >>
>> >> does ML have any equivalent of template parameters? eg
>> >>
>> >> foo!(1,int);
>
Walter Bright wrote:
Justin Johansson wrote:
I remember the discussion ... and if two intelligent folks in language
design can't agree on "inheritance direction" ... and given the
paucity of benefits ... there is only one reasonable promise to
fulfill ...
D. t
Andrei Alexandrescu wrote:
> grauzone wrote:
>>
>> Also, you should fix the auto-flattening of tuples before it's too
>> late. I think everyone agrees that auto-flattening is a bad idea, and
>> that tuples should be nestable. Flattening can be done manually with
>> an unary operator.
>>
>> (Introdu
Andrei Alexandrescu wrote:
> * Encode operators by compile-time strings. For example, instead of the
> plethora of opAdd, opMul, ..., we'd have this:
>
> T opBinary(string op)(T rhs) { ... }
>
> The string is "+", "*", etc. We need to design what happens with
> read-modify-write operators like "+
Andrei Alexandrescu schrieb:
Walter and I agreed that static foreach, although present in TDPL, poses
enough new problems to warrant its deferral to post-D2.
Please don't tell me this would solve the
foreach (member; __traits (allMembers, Class))
{
foreach (overload; __traits (getVirtual
Andrei Alexandrescu wrote:
> ...
> Any more thoughts, please let them known. ...
>
>
> Andrei
I like what I'm reading. Pretty clever!
I imagine it'd be convenient to easily distinguish between pure binary
operators and opAssign binary operators. I can easily envision myself
marking operator o
Andrei Alexandrescu:
> > Static function parameters
>
> Walter tried to implement them and ran into a number of odd semantic issues.
I'd like to know more about those semantic issues, I am curious.
Bye,
bearophile
Leandro Lucarella wrote:
What do you think?
I was inspired:
template staticInterface( T, iface ) {
static assert( is( iface == interface ) );
static assert( is( T == struct ) );
alias staticInterfaceImpl!( T, MemberTuple!( iface ) ) staticInterface;
}
template static
On Wed, 18 Nov 2009 13:21:49 -0500, Bartosz Milewski
wrote:
Andrei Alexandrescu Wrote:
Leandro Lucarella wrote:
> Andrei Alexandrescu, el 17 de noviembre a las 18:45 me escribiste:
>>> 3. If you **really** care about performance, you should only
append when you
>>> don't know the length
Don:
> The downside is that you have to add this slice/range creature into
> std.object.
I think this is acceptable. Slice structs look important enough.
Adding a stride then looks simpler: Range(start, stop, stride).
Bye,
bearophile
On Wed, 18 Nov 2009 14:03:11 -0500, Bartosz Milewski
wrote:
Andrei Alexandrescu Wrote:
One thing that Bartosz didn't mention is that "this unique" is different
than "the other unique", which I think reveals the half-bakedness of the
proposal. "The other unique" that was intensively discuss
On Thu, 19 Nov 2009 14:56:40 +0300, Steven Schveighoffer
wrote:
On Wed, 18 Nov 2009 13:21:49 -0500, Bartosz Milewski
wrote:
Andrei Alexandrescu Wrote:
Leandro Lucarella wrote:
> Andrei Alexandrescu, el 17 de noviembre a las 18:45 me escribiste:
>>> 3. If you **really** care about perf
On Thu, 19 Nov 2009 03:53:51 -0500, Don wrote:
Andrei Alexandrescu wrote:
We're entering the finale of D2 and I want to keep a short list of
things that must be done and integrated in the release. It is clearly
understood by all of us that there are many things that could and
probably sho
On Wed, 18 Nov 2009 18:14:08 -0500, Andrei Alexandrescu
wrote:
We're entering the finale of D2 and I want to keep a short list of
things that must be done and integrated in the release. It is clearly
understood by all of us that there are many things that could and
probably should be don
Steven Schveighoffer wrote:
On Thu, 19 Nov 2009 03:53:51 -0500, Don wrote:
Andrei Alexandrescu wrote:
We're entering the finale of D2 and I want to keep a short list of
things that must be done and integrated in the release. It is clearly
understood by all of us that there are many things th
On Thu, 19 Nov 2009 08:09:14 -0500, Don wrote:
Steven Schveighoffer wrote:
On Thu, 19 Nov 2009 03:53:51 -0500, Don wrote:
Andrei Alexandrescu wrote:
We're entering the finale of D2 and I want to keep a short list of
things that must be done and integrated in the release. It is clearly
u
On Thu, 19 Nov 2009 07:32:03 -0500, Denis Koroskin <2kor...@gmail.com>
wrote:
Slices are ranges. And ranges are *shrink-only*. Are you going to append
to your data structure? Use an Array instead. Slices are not suitable
for that purpose!
Arrays are ranges too. Just because the range int
Andrei Alexandrescu Wrote:
> Yes; opBinary was just given as an example. Unary operators look like this:
>
> T opUnary(string op)();
Why not do
T op(string op)(); // unary
T op(string op)(T rhs); // binary
Kyle Wrote:
> Andrei Alexandrescu Wrote:
>
> > Yes; opBinary was just given as an example. Unary operators look like this:
> >
> > T opUnary(string op)();
>
> Why not do
>
> T op(string op)(); // unary
> T op(string op)(T rhs); // binary
>
Whoops
T op(string operation)(); // unary
T op(str
I'd like a higher max size limit for static arrays:
uint[10_000_000] arr;
For the LDC compiler is a fully arbitrary limit, it can support higher values.
I'd like ldc to be free to use a higher limit.
Most/all PC CPUs & operating systems are probably going to become 64 bit, but
in D int values a
I noticed the "Metaprogramming in D : Some Real-world Examples" Meeting was
held at Microsoft Headquarters. With Google Go now the flavour of the month
will there be big support from Microsoft for D to counteract the Go onslaught...
I think we should be told...
"Ellery Newcomer" wrote in message
news:he2lm6$1h3...@digitalmars.com...
> Andrei Alexandrescu wrote:
>> Ellery Newcomer wrote:
>>> Andrei Alexandrescu wrote:
TDPL boasts the code:
void main()
{
string a = "Hall\u00E5";
wstring b = ", ";
dstring c = "V\u00
"bearophile" wrote in message
news:he3hk8$6k...@digitalmars.com...
> I'd like a higher max size limit for static arrays:
> uint[10_000_000] arr;
> For the LDC compiler is a fully arbitrary limit, it can support higher
> values. I'd like ldc to be free to use a higher limit.
>
>
> Most/all PC CPU
Simen kjaeraas, el 19 de noviembre a las 12:47 me escribiste:
> Leandro Lucarella wrote:
>
> >What do you think?
>
> I was inspired:
>
[...]
>
> Usage:
>
> interface I;
> struct S;
> static if ( staticInterface!( S, I ) ) {}
[...]
Nice! :)
--
Leandro Lucarella (AKA luca)
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> On Wed, 18 Nov 2009 18:14:08 -0500, Andrei Alexandrescu
> wrote:
> > We're entering the finale of D2 and I want to keep a short list of
> > things that must be done and integrated in the release. It is clearly
> > understood by a
== Quote from Chad J (chadj...@__spam.is.bad__gmail.com)'s article
> Andrei Alexandrescu wrote:
> > grauzone wrote:
> >>
> >> Also, you should fix the auto-flattening of tuples before it's too
> >> late. I think everyone agrees that auto-flattening is a bad idea, and
> >> that tuples should be nest
Nick Sabalausky:
> Isn't that more or less what "size_t" is for?
Do you use size_t and ptrdiff_t often in your D programs?
Bye,
bearophile
On Thu, 19 Nov 2009 17:55:35 +0300, bearophile
wrote:
Nick Sabalausky:
Isn't that more or less what "size_t" is for?
Do you use size_t and ptrdiff_t often in your D programs?
Bye,
bearophile
I do, very often (especially size_t). What's wrong with it?
Bartosz Milewski írta:
dsimcha Wrote:
The one thing that I think has been missing from this discussion is, what would
be
the alternative if we didn't have this "non-deterministic" reallocation? How
else
could you **efficiently** implement dynamic arrays?
In the long run (D3), I proposed us
On Thu, Nov 19, 2009 at 2:36 PM, bearophile wrote:
> I'd like a higher max size limit for static arrays:
> uint[10_000_000] arr;
> For the LDC compiler is a fully arbitrary limit, it can support higher
> values. I'd like ldc to be free to use a higher limit.
>
>
> Most/all PC CPUs & operating sys
bearophile wrote:
I'd like a higher max size limit for static arrays:
uint[10_000_000] arr;
Why?
On Thu, 19 Nov 2009 18:33:22 +0300, gzp wrote:
Bartosz Milewski írta:
dsimcha Wrote:
The one thing that I think has been missing from this discussion is,
what would be
the alternative if we didn't have this "non-deterministic"
reallocation? How else
could you **efficiently** implement d
Steven Schveighoffer wrote:
On Wed, 18 Nov 2009 18:14:08 -0500, Andrei Alexandrescu
wrote:
We're entering the finale of D2 and I want to keep a short list of
things that must be done and integrated in the release. It is clearly
understood by all of us that there are many things that could an
Andrei Alexandrescu wrote:
Any more thoughts, please let them known. Again, this is the ideal time
to contribute. But "meh, it's a hack" is difficult to discuss.
Well that's just like as if Bjarne Stroustrup would ask you: "What would
you have done in my place? This looked like the right thing
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Yes, it will be because the book has a few failing unittests. In fact, I
> was hoping I could talk you or David into doing it :o).
> Andrei
Unfortunately, I've come to hate the MRU idea because it would fail miserably
f
Denis Koroskin wrote:
Same here. FWIW, I strongly believe demise of T[new] was a step in a
wrong direction, and I feel highly frustrated about it. It was one of
the most anticipated features that was asked for *years*! And it's gone
when it was so close to be implemented...
The only more or l
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
3. It was mentioned in this group that if getopt() does not work in
SafeD, then SafeD may as well pack and go home. I agree. We need to
make it work. Three ideas discussed with Walter:
If that's such an issue, why don't yo
Don:
> Why?
There are C programs that use larghish static 2D arrays that can't be converted
to D1 for LDC as is, because of an arbitrary imposed limit. I'd like the D
specs to state that such limit is implementation-specific, can be different
between different compilers (but if you want you can
"Denis Koroskin" <2kor...@gmail.com> wrote in message
news:op.u3nd5txbo7c...@dkoroskin.saber3d.local...
> On Thu, 19 Nov 2009 17:55:35 +0300, bearophile
> wrote:
>
>> Nick Sabalausky:
>>> Isn't that more or less what "size_t" is for?
>>
>> Do you use size_t and ptrdiff_t often in your D programs
grauzone wrote:
Andrei Alexandrescu wrote:
Any more thoughts, please let them known. Again, this is the ideal
time to contribute. But "meh, it's a hack" is difficult to discuss.
Well that's just like as if Bjarne Stroustrup would ask you: "What would
you have done in my place? This looked lik
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Yes, it will be because the book has a few failing unittests. In fact, I
was hoping I could talk you or David into doing it :o).
Andrei
Unfortunately, I've come to hate the MRU idea because it would fail
grauzone wrote:
Denis Koroskin wrote:
Same here. FWIW, I strongly believe demise of T[new] was a step in a
wrong direction, and I feel highly frustrated about it. It was one of
the most anticipated features that was asked for *years*! And it's
gone when it was so close to be implemented...
T
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> dsimcha wrote:
> > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> >> Yes, it will be because the book has a few failing unittests. In fact, I
> >> was hoping I could talk you or David into d
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
3. It was mentioned in this group that if getopt() does not work in
SafeD, then SafeD may as well pack and go home. I agree. We need to
make it work. Three ideas discussed with Walter:
If that's such an is
Andrei Alexandrescu wrote:
opBinary does solve opIndex* morass because it only adds one function
per category, not one function per operator. For example:
struct T {
// op can be "=", "+=", "-=" etc.
E opAssign(string op)(E rhs) { ... }
// op can be "=", "+=", "-=" etc.
E opInde
Andrei Alexandrescu wrote:
You mean use a struct for the string-value pair? A struct cannot have a
ref member, so it would still need to store a pointer. (But maybe I
misunderstood the point.)
Like this:
void main(string[] commandline) {
struct Args {
string param1 = "
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Yes, it will be because the book has a few failing unittests. In fact, I
was hoping I could talk you or David in
On Thu, 19 Nov 2009 12:01:25 -0500, dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
dsimcha wrote:
> == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
>> Yes, it will be because the book has a few failing unittests. In
f
grauzone wrote:
Andrei Alexandrescu wrote:
You mean use a struct for the string-value pair? A struct cannot have
a ref member, so it would still need to store a pointer. (But maybe I
misunderstood the point.)
Like this:
void main(string[] commandline) {
struct Args {
string param
Steven Schveighoffer wrote:
On Thu, 19 Nov 2009 12:01:25 -0500, dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
dsimcha wrote:
> == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
>> Yes, it will be because the book has a fe
Martin Hanson wrote:
I noticed the "Metaprogramming in D : Some Real-world Examples" Meeting was
held at Microsoft Headquarters. With Google Go now the flavour of the month will there be
big support from Microsoft for D to counteract the Go onslaught...
I think we should be told...
Microsoft
Andrei Alexandrescu pisze:
We're entering the finale of D2 and I want to keep a short list of
things that must be done and integrated in the release. It is clearly
understood by all of us that there are many things that could and
probably should be done.
1. Currently Walter and Don are dilige
Yigal Chripun wrote:
Stewart Gordon wrote:
Yigal Chripun wrote:
a + 5, b + a //
I don't follow you. What I said was that if you have the above in a for
loop with a comma expression, you'd expect to *first* add 5 to a and
*then* add the new a to b (comma operator defines left to right orde
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Steven Schveighoffer wrote:
> > On Thu, 19 Nov 2009 12:01:25 -0500, dsimcha wrote:
> >
> >> == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
> >> article
> >>> dsimcha wrote:
> >>> > == Quote from Andr
aarti_pl pisze:
Andrei Alexandrescu pisze:
2. User-defined operators must be revamped. Fortunately Don already
put in an important piece of functionality (opDollar). What we're
looking at is a two-pronged attack motivated by Don's proposal:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIP
aarti_pl wrote:
aarti_pl pisze:
Andrei Alexandrescu pisze:
2. User-defined operators must be revamped. Fortunately Don already
put in an important piece of functionality (opDollar). What we're
looking at is a two-pronged attack motivated by Don's proposal:
http://prowiki.org/wiki4d/wiki.cgi?
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Steven Schveighoffer wrote:
On Thu, 19 Nov 2009 12:01:25 -0500, dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
dsimcha wrote:
== Quote from Andrei Alexandr
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> dsimcha wrote:
> > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> >> Steven Schveighoffer wrote:
> >>> On Thu, 19 Nov 2009 12:01:25 -0500, dsimcha wrote:
> >>>
> == Quote from Andrei A
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Steven Schveighoffer wrote:
On Thu, 19 Nov 2009 12:01:25 -0500, dsimcha wrote:
== Quote from Andrei Alexandr
On Thu, Nov 19, 2009 at 5:35 AM, Martin Hanson wrote:
> I noticed the "Metaprogramming in D : Some Real-world Examples" Meeting was
> held at Microsoft Headquarters. With Google Go now the flavour of the month
> will there be big support from Microsoft for D to counteract the Go
> onslaught...
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> > 2. After thinking about this some more, the big issue I see is ref
> > opIndex. We
> > can either:
> > a. Disallow it for both UniqueArray and ArrayBuilder.
> > b. Allow it for both UniqueArray and ArrayBui
aarti_pl:
> T opInfix(string op)(T rhs) { ... }
> T opPrefix(string op)(T rhs) { ... }
> T opPostfix(string op)(T rhs) { ... }
So you can use opInfix to define operators like a ~~ b :-)
Now you just need a way to define operator precedence level, with an int number
in 0-14 and you're done (I don
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Justin Johansson wrote:
> Andrei Alexandrescu wrote:
>> TDPL boasts the code:
>>
>> void main()
>> {
>> string a = "Hall\u00E5";
>> wstring b = ", ";
>> dstring c = "V\u00E4rld";
>> auto d = b ~ c; // d has type wstring, same as b
>>
Andrei Alexandrescu pisze:
aarti_pl wrote:
aarti_pl pisze:
Andrei Alexandrescu pisze:
2. User-defined operators must be revamped. Fortunately Don already
put in an important piece of functionality (opDollar). What we're
looking at is a two-pronged attack motivated by Don's proposal:
http://
bearophile pisze:
aarti_pl:
T opInfix(string op)(T rhs) { ... }
T opPrefix(string op)(T rhs) { ... }
T opPostfix(string op)(T rhs) { ... }
So you can use opInfix to define operators like a ~~ b :-)
Exactly. But the question is if you *REALLY* need it :-) But IMHO the
answer is up to design
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
2. After thinking about this some more, the big issue I see is ref opIndex. We
can either:
a. Disallow it for both UniqueArray and ArrayBuilder.
b. Allow it for both UniqueArray and ArrayBuilde
aarti_pl:
> I think that proposed names exactly reflect the meaning. So I would say
> it is perfectly consistent with D convention.
Dollars are money, but opDollar is not a member function that returns the price
of a struct. So I don't agree with you, or I don't understand what you mean.
Bye,
Andrei Alexandrescu, el 18 de noviembre a las 20:33 me escribiste:
> Leandro Lucarella wrote:
> >grauzone, el 19 de noviembre a las 03:47 me escribiste:
> >>Does the current proposal make things simpler at all? All you're
> >>doing is to enable the programmer to "fix" the clumsy semantics by
> >>th
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> dsimcha wrote:
> > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> >>> 2. After thinking about this some more, the big issue I see is ref
> >>> opIndex. We
> >>> can either:
> >>> a.
bearophile pisze:
aarti_pl:
I think that proposed names exactly reflect the meaning. So I would say
it is perfectly consistent with D convention.
Dollars are money, but opDollar is not a member function that returns the price
of a struct. So I don't agree with you, or I don't understand what
Bill Baxter wrote:
Note how MS still hasn't produced a C99 compiler.
They just don't see it as relevant to enough people to be financially
worthwhile.
Not even the C people care about C99. I rarely get any interest for it
with the Digital Mars C compiler.
bearophile wrote:
Most/all PC CPUs & operating systems are probably going to become 64
bit, but in D int values are 32 bit, so some years from now, when
everything is 64 bit D programs will probably keep containing:
int i; Unless D programmers will train themselves to nearly never use
int and
dsimcha, el 19 de noviembre a las 17:01 me escribiste:
> > > Unfortunately, I've come to hate the MRU idea because it would fail
> > > miserably for
> > > large arrays. I've explained this before, but not particularly
> > > thoroughly, so
> > > I'll try to explain it more thoroughly here. Let's
Thu, 19 Nov 2009 11:47:46 -0800, Bill Baxter wrote:
> It seems to me that MS expects C++ to go the way of FORTRAN and
> COBAL. Still there, still used, but by an increasingly small number of
> people for a small (but important!) subset of things. Note how MS still
> hasn't produced a C99 compil
On Thu, Nov 19, 2009 at 09:10:57PM +, retard wrote:
> I expect most
> of the every day apps to move to the cloud during the next 10 years.
> Unfortunately c++ and d missed the train here.
D can do this. My D Windowing System project, while not originally conceived
for it, is already fairly c
On Wed, Nov 18, 2009 at 5:12 PM, Andrei Alexandrescu
wrote:
> Kyle wrote:
>>
>> Andrei Alexandrescu Wrote:
>>
>>> 6. There must be many things I forgot to mention, or that cause grief to
>>> many of us. Please add to/comment on this list.
>>
>> Uniform function call syntax.
>>
>
> It's in the book
aarti_pl wrote:
I know that quite a few people here doesn't like to allow users to
define their own operators, because it might obfuscate code. But it
doesn't have to be like this. Someone here already mentioned here that
it is not real problem for programs in C++. Good libraries don't abuse
t
grauzone wrote:
Like this:
void main(string[] commandline) {
struct Args {
string param1 = "can even have default arguments";
int param2;
}
Args args = getopt!(Args)(commandline);
writefln("param1 = %s", args.param1);
}
No pointers. Instead of returning it, struc
Andrei Alexandrescu wrote:
If we use @safe and @trusted to indicate unequivocally "no escape", then
there is no analysis to be done - the hard part of the analysis has
already been done manually by the user.
The problem then becomes:
T[] foo(T[] t) { return t; }
T[] bar()
{
T[3] a;
ret
On Thu, Nov 19, 2009 at 01:26:41PM -0800, Walter Bright wrote:
> Unless such have a unique grammar that can be lexed and parsed:
>
> a :string: b
>
> where string is the user defined name, so you can do things like:
>
> a :^^: b
What if there was some magic defined at the top of the fil
On Nov 20, 09 05:26, Walter Bright wrote:
aarti_pl wrote:
I know that quite a few people here doesn't like to allow users to
define their own operators, because it might obfuscate code. But it
doesn't have to be like this. Someone here already mentioned here that
it is not real problem for progr
On Thu, Nov 19, 2009 at 04:46:55PM -0500, Adam D. Ruppe wrote:
> What if there was some magic defined at the top of the file or something, that
> could be pulled out without parsing the whole thing?
I should add that I'm not really sold on the idea of user defined operators
at all - I'm just curio
Thu, 19 Nov 2009 13:26:41 -0800, Walter Bright wrote:
> aarti_pl wrote:
>> I know that quite a few people here doesn't like to allow users to
>> define their own operators, because it might obfuscate code. But it
>> doesn't have to be like this. Someone here already mentioned here that
>> it is no
aarti_pl wrote:
Andrei Alexandrescu pisze:
aarti_pl wrote:
aarti_pl pisze:
Andrei Alexandrescu pisze:
2. User-defined operators must be revamped. Fortunately Don already
put in an important piece of functionality (opDollar). What we're
looking at is a two-pronged attack motivated by Don's pr
Thu, 19 Nov 2009 16:31:36 -0500, Adam D. Ruppe wrote:
> On Thu, Nov 19, 2009 at 09:10:57PM +, retard wrote:
>> I expect most
>> of the every day apps to move to the cloud during the next 10 years.
>> Unfortunately c++ and d missed the train here.
>
> D can do this. My D Windowing System proje
1 - 100 of 163 matches
Mail list logo
