Walter Bright wrote:
> Robert Fraser wrote:
>> BCS wrote:
>>> One thing Walter is adement about is that copy-n-paste C code must
>>> run correctly (i.e the same) in D or not compile. As for the C style
>>> type syntax, I'd be willing to see that go en-total.
>>
>> It's useful if you have a .h that
Robert Fraser wrote:
BCS wrote:
One thing Walter is adement about is that copy-n-paste C code must run
correctly (i.e the same) in D or not compile. As for the C style type
syntax, I'd be willing to see that go en-total.
It's useful if you have a .h that you both include in a C/C++ file and
BCS wrote:
One thing Walter is adement about is that copy-n-paste C code must run
correctly (i.e the same) in D or not compile. As for the C style type
syntax, I'd be willing to see that go en-total.
It's useful if you have a .h that you both include in a C/C++ file and
run through a preproce
Lutger wrote:
bearophile wrote:
Andrei Alexandrescu:
This is a great initiative. Let me add a few small points.
[...]
Please you or someone else add those points to this page, so they don't
get lost (I can't add them myself? It doesn't accept my name):
http://www.wikiservice.at/d/wiki.cgi?Lan
Walter Bright, el 14 de julio a las 14:52 me escribiste:
> Leandro Lucarella wrote:
> >The same goes for version (!X) ..., I think it should be available, there
> >are cases when the use is valid and you have to do artificial hacks like
> >version (X) else It's like Java not having functions o
Trass3r wrote:
Man, it's so obvious, yet I wouldn't have hit on that ;)
Most obvious things are obvious only in hindsight .
On Tue, 14 Jul 2009 12:42:56 -0400, Andrei Alexandrescu
wrote:
Don wrote:
- Operator overloading. "completely redone" (?)
I think they should be redone. There are several issues:
1. Currently there's no provision for "expr1[expr2] @= expr3", where @
is some binary operator. The opIndexAss
Walter Bright schrieb:
Don wrote:
In this case you may have a long function, with only a single
instruction right in the middle which needs to be changed.
void foo()
{
asm
{
mov EAX,EAX;
... lots more instructions ...
}
version (bar) asm
{
mov EAX,EAX;
Walter Bright:
> Using the bottom two bits as flags (because the pointers were aligned)
> is not all that uncommon. I've seen it done by major companies on some
> major, very successful projects.
That's done often enough, one or two bits in tagged pointers are useful to
implement various data s
Bill Baxter wrote:
On Tue, Jul 14, 2009 at 5:13 PM, Walter
Bright wrote:
Why do C and C++ (and D) make it difficult to do:
char *p;
p |= 1;
? There's no implementation difficulty in accepting such and generating
correct code for it. It's purely a matter of making what is generally
consider
On Tue, Jul 14, 2009 at 5:13 PM, Walter
Bright wrote:
> Rainer Deyke wrote:
>>
>> Walter Bright wrote:
>>>
>>> It's not about protecting idiots. It's about making the better way to do
>>> things the easier and more natural way, and making the worse more
>>> difficult.
>>
>> Making the better way ea
Don wrote:
In this case you may have a long function, with only a single
instruction right in the middle which needs to be changed.
void foo()
{
asm
{
mov EAX,EAX;
... lots more instructions ...
}
version (bar) asm
{
mov EAX,EAX;
}
asm
{
On Tue, Jul 14, 2009 at 5:02 PM, Walter
Bright wrote:
> Bill Baxter wrote:
>>
>> You do realize you're being patronizing, right? "I have so much
>> experience with these things, and I know the right way to write code,
>> and you don't, so I'm not going to give you this thing you request
>> because
Rainer Deyke wrote:
Walter Bright wrote:
It's not about protecting idiots. It's about making the better way to do
things the easier and more natural way, and making the worse more
difficult.
Making the better way easy is a worthwhile goal. Making the worse way
more difficult is not. A progra
Bill Baxter wrote:
You do realize you're being patronizing, right? "I have so much
experience with these things, and I know the right way to write code,
and you don't, so I'm not going to give you this thing you request
because it's not good for you".
Sure. There's some of that in every langua
Lutger:
> Isn't .C#'s Nullable a library thing? (It's quite useful for database
> crap)
C# nullable are nice because they have syntax support, so they are more handy
than a purely library solution. But I was not talking about C# nullables :-)
It's kind of the opposite, I was talking about non-n
bearophile wrote:
> Lutger:
>>Can't nullable / non-nullable be done in library?<
>
> Yes, of course, people in the Scheme language have shown that you can do
> almost everything in library code. But to do that you need (beside fixing
> D library code, because the default now becomes non-null obje
Lutger:
>Can't nullable / non-nullable be done in library?<
Yes, of course, people in the Scheme language have shown that you can do almost
everything in library code. But to do that you need (beside fixing D library
code, because the default now becomes non-null object references) a "pluggable
Walter Bright Wrote:
> Nevertheless, I expect the rate of change to slow down after D2 is released.
Seeing the ideas they want to add to C#4.5, I think its rate of change isn't
that much low still :-)
My humble opinion is that D2beta is too much early to reduce its rate of change
a lot :-)
Bye
bearophile wrote:
> Andrei Alexandrescu:
>> This is a great initiative. Let me add a few small points.
>> [...]
>
> Please you or someone else add those points to this page, so they don't
> get lost (I can't add them myself? It doesn't accept my name):
> http://www.wikiservice.at/d/wiki.cgi?Langu
Leandro Lucarella:
> And even for things that are relevant to the language, I don't think
> D should be attached to *any* backend, not DMD, not LLVM. Things required
> by the specification should be doable in any backend if you plan to see
> more compilers in the future.
I agree that restricting D
Andrei Alexandrescu:
> This is a great initiative. Let me add a few small points.
> [...]
Please you or someone else add those points to this page, so they don't get
lost (I can't add them myself? It doesn't accept my name):
http://www.wikiservice.at/d/wiki.cgi?LanguageDevel#section2
You can also
Walter Bright wrote:
> It's not about protecting idiots. It's about making the better way to do
> things the easier and more natural way, and making the worse more
> difficult.
Making the better way easy is a worthwhile goal. Making the worse way
more difficult is not. A programming language sho
On Tue, Jul 14, 2009 at 2:52 PM, Walter
Bright wrote:
> Leandro Lucarella wrote:
>>
>> The same goes for version (!X) ..., I think it should be available, there
>> are cases when the use is valid and you have to do artificial hacks like
>> version (X) else It's like Java not having functions o
Lutger wrote:
Has it been planned how D will proceed after D2 is finalized?
I'm curious to know whether the D designers intent to develop new features
in a backwards-compatible manner (if possible) or that there will be a third
branch. This is assuming that the language will not be considered
Lars T. Kyllingstad Wrote:
> Eldar Insafutdinov wrote:
> > dsimcha Wrote:
> >
> >> == Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
> >>> On Tue, Jul 14, 2009 at 12:42 PM, Andrei
> >>> Alexandrescu wrote:
> > - opImplicitCast
> I think alias this should render
Leandro Lucarella wrote:
The same goes for version (!X) ..., I think it should be available, there
are cases when the use is valid and you have to do artificial hacks like
version (X) else It's like Java not having functions or global
variable. You're just annoying people that know what they
Has it been planned how D will proceed after D2 is finalized?
I'm curious to know whether the D designers intent to develop new features
in a backwards-compatible manner (if possible) or that there will be a third
branch. This is assuming that the language will not be considered finished
of cou
bearophile, el 14 de julio a las 16:37 me escribiste:
> Robert Clipsham:
> >What exactly is it you mean by this?<
>
> I keep saying wrong things every day, so this too can be wrong.
>
> DMD back-end is not bad, it compiles quite quickly, and there are many
> tests where the binary it produces is
Other, less technical items:
A clear and "finalized" spec. If it isn't implemented, it should be yanked
(or clearly marked as pending)
A plan for library support. Not just Tango, but also Phobos. D1 Phobos could
not evolve.
Don Wrote:
> A lot of frustration has been expressed on the newgrou
Walter Bright, el 14 de julio a las 10:01 me escribiste:
> Bill Baxter wrote:
> >But from where I sit it looked like Walter didn't really convince
> >anyone. To me this seems like a point where D is overly patronizing,
> >to use the phrase from a recent post.
>
> You could argue that, but it also
On Tue, Jul 14, 2009 at 1:37 PM, bearophile wrote:
> Robert Clipsham:
> But LLVM offers many interesting things that are hard to do with DMD's
> back-end, often such things are already implemented in LLVM (maybe not fully
> refined yet, but they are working on it) and they are waiting to be used
On Tue, Jul 14, 2009 at 12:04 PM, Walter
Bright wrote:
> Bill Baxter wrote:
>>
>> I do think you make a convincing argument that in general lots of
>> micro ifdefs everywhere is not the right approach.
>> But I remain unconvinced that potential for abuse is a good reason to
>> disallow finer scale
Andrei Alexandrescu wrote:
1. It's pretty clear what is happening for each system.
Not clear to me. It's happened to me more than once to fix a function
without knowing that it's version()ed (your fault: you didn't indent it)
and that there's a corresponding Windows function some miles away.
Eldar Insafutdinov wrote:
dsimcha Wrote:
== Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
On Tue, Jul 14, 2009 at 12:42 PM, Andrei
Alexandrescu wrote:
- opImplicitCast
I think alias this should render that unnecesary.
'alias this' might cover a lot of cases, but t
Robert Clipsham:
>What exactly is it you mean by this?<
I keep saying wrong things every day, so this too can be wrong.
DMD back-end is not bad, it compiles quite quickly, and there are many tests
where the binary it produces is a bit faster than the binary produced by LDC.
But LLVM offers many
Stewart Gordon, el 14 de julio a las 18:39 me escribiste:
> A nice idea; however, my feeling is that there are too many places for
> proposing D features. At the moment, feature proposals are split
> between:
>
> - the newsgroups
> - the eigenpoll - http://all-technology.com/eigenpolls/dwishlist/
dsimcha Wrote:
> == Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
> > On Tue, Jul 14, 2009 at 12:42 PM, Andrei
> > Alexandrescu wrote:
> > >> - opImplicitCast
> > >
> > > I think alias this should render that unnecesary.
> > 'alias this' might cover a lot of cases, but t
Walter Bright wrote:
Andrei Alexandrescu wrote:
In my approach they are laid as you see them, which I find very
well-organized.
There is no duplication in:
[snip]
I said there's either duplication or complication.
But there's no hard and fast rule here, and since you are doing the
actual
Julian Salazar wrote:
My final question is just about how I would go about contributing to the
Inline Assembler specification. I found that you generate the language
spec from the trunk/docsrc folder on the Phobos SVN repo on dsource.org.
So, am I right to think that I could just download the d
Bill Baxter wrote:
I do think you make a convincing argument that in general lots of
micro ifdefs everywhere is not the right approach.
But I remain unconvinced that potential for abuse is a good reason to
disallow finer scale version() statements.
It's where the line between micro and fine is
Reply to Jacob,
I've read posts in several threads complaining about the C
compatibility, the latest was the % operator. Other complains are that
you can use the C syntax for pointers, arrays and function pointers.
Also the "Case range statement" thread that complained (among other
things) about
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Then I have the function right there with all versioned
implementations. To me that seems better than Phobos' existing style
of version'ing large portions of code, which inevitably results in
duplicating a lot of the f
I've read posts in several threads complaining about the C
compatibility, the latest was the % operator. Other complains are that
you can use the C syntax for pointers, arrays and function pointers.
Also the "Case range statement" thread that complained (among other
things) about fall through i
On Tue, Jul 14, 2009 at 1:32 PM, Andrei
Alexandrescu wrote:
>>
>> Oh, wow! :)
>
> Double-wow: you can alias to a function that returns a ref.
My head just exploded.
On Tue, 14 Jul 2009 12:37:47 -0400, Bill Baxter wrote:
On Tue, Jul 14, 2009 at 7:26 AM, Leandro Lucarella
wrote:
Kagamin, el 9 de julio a las 09:46 me escribiste:
DiP2 is here. Check it.
http://www.prowiki.org/wiki4d/wiki.cgi?DiPs
http://www.prowiki.org/wiki4d/wiki.cgi?DiP2
ps code markup
Don's list is:
>
> - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
> - Multithreading (II): Will some form of message parsing be included?
> - Operator overloading. "completely redone" (?)
> - opImplicitCast
> - is T[new] still going to happen?
> - Phobos I/O -- Andrei h
Stewart Gordon wrote:
A nice idea; however, my feeling is that there are too many places for
proposing D features. At the moment, feature proposals are split between:
- the newsgroups
- the eigenpoll - http://all-technology.com/eigenpolls/dwishlist/
- the wiki - http://www.prowiki.org/wiki4d/w
A nice idea; however, my feeling is that there are too many places for
proposing D features. At the moment, feature proposals are split between:
- the newsgroups
- the eigenpoll - http://all-technology.com/eigenpolls/dwishlist/
- the wiki - http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestL
Jarrett Billingsley wrote:
On Tue, Jul 14, 2009 at 1:02 PM, dsimcha wrote:
== Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
On Tue, Jul 14, 2009 at 12:42 PM, Andrei
Alexandrescu wrote:
- opImplicitCast
I think alias this should render that unnecesary.
'alias this'
On Tue, Jul 14, 2009 at 10:01 AM, Walter
Bright wrote:
> Bill Baxter wrote:
>>
>> But from where I sit it looked like Walter didn't really convince
>> anyone. To me this seems like a point where D is overly patronizing,
>> to use the phrase from a recent post.
>
> You could argue that, but it also
On Tue, Jul 14, 2009 at 10:02 AM, dsimcha wrote:
> == Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
>> On Tue, Jul 14, 2009 at 12:42 PM, Andrei
>> Alexandrescu wrote:
>> >> - opImplicitCast
>> >
>> > I think alias this should render that unnecesary.
>> 'alias this' might
On Tue, Jul 14, 2009 at 1:02 PM, dsimcha wrote:
> == Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
>> On Tue, Jul 14, 2009 at 12:42 PM, Andrei
>> Alexandrescu wrote:
>> >> - opImplicitCast
>> >
>> > I think alias this should render that unnecesary.
>> 'alias this' might c
Walter Bright wrote:
Andrei Alexandrescu wrote:
Then I have the function right there with all versioned
implementations. To me that seems better than Phobos' existing style
of version'ing large portions of code, which inevitably results in
duplicating a lot of the functionality in two places.
Andrei Alexandrescu wrote:
Then I have the function right there with all versioned implementations.
To me that seems better than Phobos' existing style of version'ing large
portions of code, which inevitably results in duplicating a lot of the
functionality in two places.
I wouldn't consider
Bill Baxter wrote:
But from where I sit it looked like Walter didn't really convince
anyone. To me this seems like a point where D is overly patronizing,
to use the phrase from a recent post.
You could argue that, but it also took a long time to convince many
about the merit of const and immu
== Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
> On Tue, Jul 14, 2009 at 12:42 PM, Andrei
> Alexandrescu wrote:
> >> - opImplicitCast
> >
> > I think alias this should render that unnecesary.
> 'alias this' might cover a lot of cases, but this is the pretty big
> one th
I appreciate the reply, and I guess that your point about separating
dependencies into different modules is a good form of version management.
I'll still be using the version(x86) asm {...} else version(x86_64) asm
{...} syntax for a while though. But I'm done arguing that point.
My final ques
On Tue, Jul 14, 2009 at 12:42 PM, Andrei
Alexandrescu wrote:
>> - opImplicitCast
>
> I think alias this should render that unnecesary.
'alias this' might cover a lot of cases, but this is the pretty big
one that I can think of: consider a Bigint or the like. You might
want to use such a type tra
Don wrote:
A lot of frustration has been expressed on the newgroup about lack of a
clear public plan for D2.0. I don't think we're in a position to create
a road-map. But, let's at least agree on which countries we'll probably
visit before we reach our final destination .
This is a great init
On Tue, Jul 14, 2009 at 7:26 AM, Leandro Lucarella wrote:
> Kagamin, el 9 de julio a las 09:46 me escribiste:
>> DiP2 is here. Check it.
>>
>> http://www.prowiki.org/wiki4d/wiki.cgi?DiPs
>> http://www.prowiki.org/wiki4d/wiki.cgi?DiP2
>>
>> ps code markup is not very nice.
>
> It would be very nice
Bill Baxter wrote:
On Mon, Jul 13, 2009 at 10:05 PM, Walter
Bright wrote:
Julian Salazar wrote:
It's been rehashed here several times (not to rag on you, just to point out
that it isn't something that's been overlooked). To sum up, I've worked a
lot with both styles - #ifdef, and separating depe
Andrei Alexandrescu, el 14 de julio a las 10:10 me escribiste:
> Leandro Lucarella wrote:
> >Walter, I would *really* like to know if you plan to take DIPs seriously,
> >I don't think DIPs will be useful and taken seriously by the community
> >without some kind of "official" support.
>
> I persona
On Mon, Jul 13, 2009 at 8:24 PM, Walter
Bright wrote:
> Julian Salazar wrote:
>>
>> Hi, I'm new here to the community but I've been using D for a while now,
>> and I have to say that it's a great programming language. I'd like to get
>> involved in this community and help shape this language.
>
> W
Leandro Lucarella wrote:
Walter, I would *really* like to know if you plan to take DIPs seriously,
I don't think DIPs will be useful and taken seriously by the community
without some kind of "official" support.
I personally want to take DIP seriously and write a couple myself. My
understanding
Don, el 14 de julio a las 11:53 me escribiste:
> A lot of frustration has been expressed on the newgroup about lack of a clear
> public plan for D2.0. I don't think we're in a position to create a road-map.
> But, let's at least agree on which countries we'll probably visit before we
> reach our
Brad Roberts, el 11 de julio a las 22:24 me escribiste:
> I meant that more as a "don't feel you can't edit it because you're not the
> author of it" or that I owned the idea. I'll be happy to update it as needed.
I think the author should be some kind of maintainer. Anyone can update
the DIP, bu
Kagamin, el 9 de julio a las 09:46 me escribiste:
> DiP2 is here. Check it.
>
> http://www.prowiki.org/wiki4d/wiki.cgi?DiPs
> http://www.prowiki.org/wiki4d/wiki.cgi?DiP2
>
> ps code markup is not very nice.
It would be very nice if you include at least the abstract in the mail, so
it's easier t
Leandro Lucarella, el 8 de julio a las 17:19 me escribiste:
> Michiel Helvensteijn, el 8 de julio a las 21:27 me escribiste:
> > Leandro Lucarella wrote:
> >
> > > Hello, I just created a DIP (D Improvement Proposal) index[1] and the
> > > first DIP (DIP1), a DIP template[2].
> >
> > Has the D
On Tue, 14 Jul 2009 15:03:15 +0100, Robert Clipsham wrote:
> Jesse Phillips wrote:
>> I've created a small overview page of the available compilers on
>> Wiki4D. The idea is not to contain much concrete information, but point
>> users in the correct direction. However, for the information that is
On Mon, Jul 13, 2009 at 10:05 PM, Walter
Bright wrote:
> Julian Salazar wrote:
> It's been rehashed here several times (not to rag on you, just to point out
> that it isn't something that's been overlooked). To sum up, I've worked a
> lot with both styles - #ifdef, and separating dependencies into
bearophile wrote:
- making D2 fitter for the LLVM back-end;
I've noticed you keep mentioning this. What exactly is it you mean by
this? If you mean allowing the dmd front end to be identical in both dmd
and ldc, I don't think that will ever happen (although getting it close
should be possibl
Jesse Phillips wrote:
I've created a small overview page of the available compilers on Wiki4D. The
idea is not to contain much concrete information, but point users in the
correct direction. However, for the information that is there I want to make
sure that it is correct and clear what is bei
Don wrote:
A lot of frustration has been expressed on the newgroup about lack of a
clear public plan for D2.0. I don't think we're in a position to create
a road-map. But, let's at least agree on which countries we'll probably
visit before we reach our final destination .
Everyone knows there
Don wrote:
A lot of frustration has been expressed on the newgroup about lack of a
clear public plan for D2.0. I don't think we're in a position to create
a road-map. But, let's at least agree on which countries we'll probably
visit before we reach our final destination .
Everyone knows there
Don wrote:
A lot of frustration has been expressed on the newgroup about lack of a
clear public plan for D2.0. I don't think we're in a position to create
a road-map. But, let's at least agree on which countries we'll probably
visit before we reach our final destination .
Everyone knows there
Don:
>Let's get everything on the table.<
Thank you for this thread, Don, recently I too have tried to start something
like it :-)
> - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
> - Multithreading (II): Will some form of message parsing be included?
> - Operator ove
A lot of frustration has been expressed on the newgroup about lack of a
clear public plan for D2.0. I don't think we're in a position to create
a road-map. But, let's at least agree on which countries we'll probably
visit before we reach our final destination .
Everyone knows there are a multi
Don wrote:
I've just put a comment on bug 3171, I'm not sure that we really want
IEEE behaviour. It obeys a == b * nearbyint(a/b) + a % b, but...
I saw that. Wild. But I think we should conform to IEEE behavior, even
if it seems strange.
Walter Bright wrote:
Don wrote:
Close, but that's technically not true in the case where abs(a/b) >
long.max. (The integer doesn't have to fit into a 'long').
In IEEE754, r= a % b is defined by the mathematical relation r = a –
b * n , where n is the integer nearest the exact number a/b ;
Julian Salazar wrote:
Hi, I'm new here to the community but I've been using D for a while now,
and I have to say that it's a great programming language. I'd like to
get involved in this community and help shape this language.
Welcome!
I'm just wondering about a minor issue: why are conditiona
81 matches
Mail list logo
