Andrei Alexandrescu wrote:
On 1/17/11 2:47 AM, Don wrote:
Andrei Alexandrescu wrote:
[snip]
This is a new example of an old issue; it is in no way specific to 64
bits.
Any expression which contains a size-extension AND a signed<->unsigned
implicit conversion is almost always a bug. (un
Andrei Alexandrescu wrote:
We've spent a lot of time trying to improve the behavior of integral
types in D. For the most part, we succeeded, but the success was
partial. There was some hope with the polysemy notion, but it ultimately
was abandoned because it was deemed too difficult to implemen
Trass3r wrote:
I think the website layout should be rethought, couldn't even find the
"Programming in D for C++ Programmers" page I wanted to show to a
workmate without an explicit search.
Imho it's important to have such comparison pages easily accessible
cause many people think "why should I l
Michel Fortin wrote:
On 2011-01-11 20:28:26 -0500, Steven Wawryk said:
Why not choose which of these abstractions is most appropriate in a
given situation instead of trying to shoe-horn both concepts into a
single abstraction, and provide for easy conversion between them?
When character repr
spir wrote:
On 01/11/2011 09:11 PM, Ary Borenszweig wrote:
"Welcome to D. Do you program in C, Javascript, Python or Ruby? Cool!
Then you
will feel at home."
That phrase currently ends like this:
"You don't? Oh, sorry, you will have to learn that some names are all
lowercase,
some not."
Bu
Andrei Alexandrescu wrote:
On 1/11/11 11:21 AM, Ary Borenszweig wrote:
Why care where they come from? Why not make them intuitive? Say, like,
"Always
camel case"?
If there's enough support for this, I'll do it.
Andrei
++vote.
Bear in mind that with D's spell checker, the error message is:
Tomek Sowin'ski wrote:
A while ago I pointed out that the result of an immutably pure function (all
arguments immutable, doesn't mutate globals) can be safely converted to
immutable. More here:
http://d.puremagic.com/issues/show_bug.cgi?id=5081
It helps with building complex immutable structur
Max Samukha wrote:
On 01/06/2011 09:28 PM, Robert Clipsham wrote:
Put each of those implementations in its own file, then call it several
times. Look at the binary size for each implementation, also run
`strings ctfeTest` if you're on a *nix. This should give you your
answer :)
The problem
Andrei Alexandrescu wrote:
On 1/6/11 9:18 AM, Don wrote:
Walter Bright wrote:
Nick Sabalausky wrote:
"Caligo" wrote in message
news:mailman.451.1294306555.4748.digitalmar...@puremagic.com...
On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
wrote:
That's pretty much what I'
Walter Bright wrote:
Nick Sabalausky wrote:
"Caligo" wrote in message
news:mailman.451.1294306555.4748.digitalmar...@puremagic.com...
On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
wrote:
That's pretty much what I'm afraid of, losing my grip on how the whole
thing works if there are multiple
Sönke Ludwig wrote:
Am 01.01.2011 23:22, schrieb Robert Clipsham:
Having seen a post by Peter Alexander (in Re: D for game development),
mentioning some of the issues he's hit I thought I'd post this. I've
been in his shoes (every other time I use D it seems), and feel I should
ask - who here us
Peter Alexander wrote:
On 1/01/11 4:55 PM, Guilherme Vieira wrote:
On Fri, Dec 31, 2010 at 4:08 PM, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>>
wrote:
A discussion to which I think some of us could add value:
http://stackoverflow.com/questions/4516283/the-d-programming-
spir wrote:
Hello,
[This is another currently unfixed point of D2 that prevents us implementing
our project the way we wish it.]
AFAIK, using '$' for custom collection types is not yet possible: oDollar is simply not
implemented (correct?). But why do we need it? I do not understand the logi
spir wrote:
On Thu, 30 Dec 2010 07:46:19 +0100
Don wrote:
This problem has already hit Phobos. We inserted a hack so that sqrt(2)
will work. But exp(1) doesn't work.
Note that the problems really arise because we've inherited C's rather
cavalier approach to implicit conversio
so wrote:
This problem has already hit Phobos. We inserted a hack so that
sqrt(2) will work. But exp(1) doesn't work.
Note that the problems really arise because we've inherited C's rather
cavalier approach to implicit conversion.
Classifying 2 as an int was a very wrong start.
Exactly. It's
bearophile wrote:
Don:
No. People expect sqrt(2) to compile, and to return 1.414
Then people probably need to use sqrt(2.0) or sqrt(cast(double)2).
I've got a lot of sympathy for the first alternative (absolutely NONE
for the second!). But unfortunately, the language allows sqrt(
Manfred_Nowak wrote:
Don wrote:
0 converts to double using implicit conversions.
The coder should know this while typing.
The coder should know about the possible problems while typing.
Because the coder could have typed `0.0' instead of `0', the coder probably
wanted the co
BACKGROUND:
D currently uses a very simple rule for parameter matching:
* it matches exactly; OR
* it matches using implicit conversions; OR
* it does not match.
There's an important extra feature: polysemous literals (those which can
be interpreted in multiple ways) have a preferred interpretat
%u wrote:
Hi,
I've been trying to make my own run-time library for D, but I've come across a
dead end: *any* library I make will inherently depend on SNN.lib, and there
are no headers for that C run-time library.
How can I write my own library in place of SNN.lib if I do not know what the
funct
JimBob wrote:
"Robert Jacques" wrote in message
news:op.voeybap626s...@sandford...
On Tue, 28 Dec 2010 00:32:37 -0700, %u wrote:
As per the docs, align behaves in the manner of the companion C++ compile.
DMC only defines align(1) and align(4), so they're the only two that work.
So this isn
bearophile wrote:
Stanislav Blinov:
...which quickly expands to a lot of *long* import lines, with "don't
forget to add another" constantly pushing the door-bell.
That's redundancy is "making your subsystems interfaces explicit". I see that
you and other people here fail to understand this,
bearophile wrote:
Je'rome M. Berger:
I have almost never used inline assembler even in languages that support it. Of
course, this is only a sub-point of your point 6: using inline assembly in a
language as slow as Python would be completely pointless.<
For scientific computing this is bette
Mariusz Gliwiński wrote:
Monday 27 December 2010 @ 17:18:17 Daniel Gibson:
Am 27.12.2010 17:01, schrieb Caligo:
On Mon, Dec 27, 2010 at 7:20 AM, Jonathan M Davis mailto:newshou...@digitalmars.com>> wrote:
> > 11. generative programming
>
> Does someone have a pointer to any kind
bearophile wrote:
Walter Bright:
I thought the idea that break and continue were bad died about 25 years ago.
Pascal didn't allow them, and pretty much everyone hated the workaround of
having to use flag variables.
You need to add some shades of grey to your palette. break, continue and goto
Alex_Dovhal wrote:
"Don" wrote:
In order for CTFE code to call pre-compiled code, three things are
required:
(1) the compiler needs to be able to find the file (.obj/.lib/shared
library) containing the compiled code;
(2) the compiler needs to be able to load the module and cal
Nick Voronin wrote:
On Sat, 18 Dec 2010 02:17:46 +0100
Don wrote:
Nick Voronin wrote:
btw, is there no explicit alignment for variables in D at all?
align(8) double d; compiles if d is global, but it does nothing.
That's a regression. Large globals are always aligned to a 16-byte
bou
Alex_Dovhal wrote:
"Don" wrote:
I don't think it's quite the same. In a makefile, every executable is
listed, and so you can have some degree of control over it. But in this
scenario, the compiler is making calls to arbitrary shared libraries with
arbitrary parameters.
I
VladD2 wrote:
Don Wrote:
I
think VladD2 is right: You need to keep track of both "current" system and
"target" system. Unfortunately, there is some information about the "target"
system the compile-time code wouldn't be able discern without givi
Nick Sabalausky wrote:
"foobar" wrote in message
news:ieijt6$21m...@digitalmars.com...
Don Wrote:
VladD2 wrote:
Don Wrote:
Suppose the pre-compiled code, when run, asks what CPU it's on. What's
the answer? Is it X or Y?
Current: X
Target: Y
Macro - a plugin to the c
Jeff Nowakowski wrote:
On 12/18/2010 07:55 AM, Caligo wrote:
If there is going to be a D3, will it be backwards compatible with D2?
And why is work still being done on the D1 compiler? Shouldn't it be
marked
deprecated so people stop using it and move to D2?
D1 is stable and only bug fixes
spir wrote:
On Sat, 18 Dec 2010 13:46:11 +0100
Don wrote:
spir wrote:
On Sat, 18 Dec 2010 01:08:20 -0800
Jonathan M Davis wrote:
Thank you for the explanation about strongly pure funcs calling weakly pure
ones --this fully makes sense.
I would like weakly pure to include output funcs
VladD2 wrote:
Don Wrote:
Suppose the pre-compiled code, when run, asks what CPU it's on. What's
the answer? Is it X or Y?
Current: X
Target: Y
Macro - a plugin to the compiler. It works on the same platform as the
compiler, but generates code through the API which abstracts the
spir wrote:
On Sat, 18 Dec 2010 01:08:20 -0800
Jonathan M Davis wrote:
Thank you for the explanation about strongly pure funcs calling weakly pure
ones --this fully makes sense.
I would like weakly pure to include output funcs, and exclude all
possibilities to modify (non-local) state.
The
Steven Schveighoffer wrote:
On Fri, 17 Dec 2010 09:39:19 -0500, Don wrote:
A function which has immutably pure parameters can undergo *some*
optimisation, even if the return value is a mutable pointer.
For example, if the parameters are identical for both calls, you can
do a deepdup of the
foobar wrote:
Don Wrote:
Another one of the big differences is that D doesn't allow compile-time
code to call external functions. Although it could certainly be done, it
raises some big issues. Eg, we cannot assume that the target CPU is the
same as the one we're running on.
Nick Voronin wrote:
I found this on bugzilla.
http://d.puremagic.com/issues/show_bug.cgi?id=2278
So it's not really a bug. Yet there is no simple workaround. And gap
between int and double looks strange when stack frame itself is unaligned.
Interestingly, since I filed that bug, DMD for MacOS
Ary Borenszweig wrote:
This is very serious. Walter and the rest always complain that C++ is very hard
to
understand, has a very long and verbose syntax and only "a few" can really
master
it. And look at that code. It's impossible to understand. One has to jump from
one
place to another, back
VladD2 wrote:
Hi,
I'm one of Nemerle developers.
Cool!
From an implementation point of view, the differences between Nemerle
macros and string mixins are mostly syntactic.
You are deeply mistaken!
I'd advise to study the Nemerle macro-system.
You missed: pattern matching,
Yes, you've g
loser wrote:
Andrei Alexandrescu Wrote:
On 12/17/10 10:23 AM, Justin Johansson wrote:
On 17/12/10 06:52, Andrei Alexandrescu wrote:
On 12/16/10 1:30 PM, Jacob Carlborg wrote:
The point here isn't that we want "a" and "b" to be replaced with "_"
the point is that we want to get rid of the str
Steven Schveighoffer wrote:
On Fri, 17 Dec 2010 02:42:14 -0500, bearophile
wrote:
http://www.reddit.com/r/programming/comments/enajl/purity_in_d_language/
Bye,
bearophile
You've got two statements here which are both sort-of true, but taken
together are not correct:
<1>
Another inaccu
bearophile wrote:
http://www.reddit.com/r/programming/comments/enajl/purity_in_d_language/
Bye,
bearophile
Nice.
BTW you're incorrectly attributing some things to me. Although I
recently championed the 'weakly pure' idea, I think Bruno made the
original proposal.
Alex_Dovhal wrote:
"Don" wrote:
Agreed. I've just looked through some code that I thought used them
extensively, but found only two complex literals: 1i (dozens of instances)
and 2i (one instance).
So if D removes complex literals what the proposed name for Imaginary One
Jacob Carlborg wrote:
On 2010-12-14 13:05, Don wrote:
Graham St Jack wrote:
On 14/12/10 20:33, Vladimir Panteleev wrote:
On Tue, 14 Dec 2010 09:30:46 +0200, Graham St Jack
wrote:
There is of course the worry that it could get so easy that everyone
starts doing it, and we have (relatively
Graham St Jack wrote:
On 14/12/10 20:33, Vladimir Panteleev wrote:
On Tue, 14 Dec 2010 09:30:46 +0200, Graham St Jack
wrote:
There is of course the worry that it could get so easy that everyone
starts doing it, and we have (relatively) impenetrable code everywhere
instead of just deep in the
Jesse Phillips wrote:
Don Wrote:
I can't really escape the feeling that 'const' guarantees too little.
It makes guarantees to the caller, but tells the callee *nothing*.
But it tells the callee exactly what it does, (assuming you unintuitive associate that const objects
Brad Roberts wrote:
On 12/13/2010 2:54 PM, Don wrote:
I can't really escape the feeling that 'const' guarantees too little.
It makes guarantees to the caller, but tells the callee *nothing*.
As far as I'm concerned, that's exactly what I want const for. The caller c
Lars T. Kyllingstad wrote:
On Mon, 13 Dec 2010 09:29:15 -0600, Andrei Alexandrescu wrote:
On 12/13/10 6:11 AM, bearophile wrote:
Andrei:
http://erdani.com/tdpl/2010-12-08-ACCU.pdf
I have a small question. At page 34 of the slides it says:
- Built-in complex types are being replaced by libr
Walter Bright wrote:
bearophile wrote:
Andrei:
D's constrained templates were introduced on 17 June 2008 and they've
been
a smashing hit. Virtually all of Phobos uses them, and I'm sure a lot of
generic client code. They take half a minute to explain and solve a
difficult problem in a very si
Andrei Alexandrescu wrote:
On 12/13/10 9:28 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/10/10 4:10 PM, foobar wrote:
Don Wrote:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of '
Andrei Alexandrescu wrote:
On 12/10/10 4:10 PM, foobar wrote:
Don Wrote:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
I agree with don.
IMH
David Nadlinger wrote:
On 12/11/10 8:18 PM, Andrej Mitrovic wrote:
I've seen some tools that can convert OMF> COFF, but never the other
way around.
Well, there is e.g. »coff2omf« from DigitalMars, but I haven't had any
success with it.
David
objconv (available at www.agner.org) now claim
Andrei Alexandrescu wrote:
On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:
On 12/10/10 19:26, Ary Borenszweig wrote:
http://vimeo.com/17420638
A very interesting talk.
I used to like D. To write code in a high level while at the same
time being very close to the machine, with class i
Michel Fortin wrote:
On 2010-12-10 17:12:16 -0500, Don said:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
One problem I'm starting to rea
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
Andrei Alexandrescu wrote:
On 12/10/10 12:47 PM, Craig Black wrote:
auto ref should work for non-templates and generate only one function.
The current implementation of auto ref originates in a misunderstanding.
Andrei
Thanks for the response. I assume Walter is aware of this problem? What
Fawzi Mohamed wrote:
If one could declare return or out types as unique (note that unique is
*not* part of the type, it is like the storage attributes), these
methods could be implicitly castable to const or immutable, allowing
nicer code.
Constructors *might* return unique objects (an objec
Lutger Blijdestijn wrote:
Jonathan M Davis wrote:
On Friday 26 November 2010 11:03:03 Andrei Alexandrescu wrote:
I wonder what would be a good deprecation schedule. Consider
http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.
We should now slowly deprecate std.utf.count. How sho
Stephan wrote:
On 07.12.2010 06:57, %u wrote:
Yay for more comments like this one.
Don 2010-12-06 11:53:27 PST
--
Bearophile -- That's an interesting [automatic fuzzy testing]link.
Currently,
DMD back-end bugs are
being found at the rate of about 3 per year. So yes, fuzzy testing of
Don wrote:
Dmitry Olshansky wrote:
Well, to keep things short, double.min returns something weird.
See the following for demonstration:
import std.stdio;
void main(){
double r = double.max, r2 = double.min;
writeln(r);//1.79769e+308
r *= 2;//test if it's max
writ
Dmitry Olshansky wrote:
Well, to keep things short, double.min returns something weird.
See the following for demonstration:
import std.stdio;
void main(){
double r = double.max, r2 = double.min;
writeln(r);//1.79769e+308
r *= 2;//test if it's max
writeln(r); // infinity, ok
Andrei Alexandrescu wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs there should be no official
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs there should be no official
implementation of opEquals, opCmp etc. All the compiler needs
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
But this disallows comparisons with rvalues.
eg,
Foo bar() { Foo x = 1; return x; }
Foo y=1;
assert( y == bar() ); // doesn't compile
You can get around this by declaring a non-ref opEqual
Jesse Phillips wrote:
foobar Wrote:
how would the to! usage look like with these additions? I suspect at that stage
the benefits of to! genericity will be lost.
to!(int)("1010101", 2); / base 2 ?
to!(int)(base!(2)("1010101"));
base!() returns a struct which can be created with strings/int
Jonathan M Davis wrote:
On Thursday, December 02, 2010 01:18:31 Don wrote:
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immu
retard wrote:
Thu, 02 Dec 2010 12:07:19 +0200, so wrote:
I find this D language advocacy in Wikipedia disgusting - clearly, you
should document notable features of D, but the main objective cannot be
as much visibility as possible.
I think that if a language has real technical merits, this
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immutable
args and again for mutable ones.
Doesn't 'inout' do almost the same thing?
Bruno Medeiros wrote:
On 06/11/2010 01:32, Don wrote:
Pure functions are allowed to read immutable global variables.
Currently, this even includes globals which are initialized from inside
'static this()'.
Here's an example of how this can be a problem:
immutable int unstable;
Peter Alexander wrote:
D does not support logical const due to the weak guarantees that it
provides.
So, without logical const, how are D users supposed to provide lazy
evaluation and memoization in their interfaces, given that the interface
should *seem* const, e.g.
class Matrix
{
double
Jack wrote:
The post "C#'s greatest mistakes" prompts/begs this post. Have at it,
pick up the ball and run with it, don't be shy. I expect Walter and
Andrei to answer (if Walter and Andrei so dare!) after others' posts have
stopped or stagnated into that cesspool of threaded discussion that is
Jens Mueller wrote:
Walter Bright wrote:
Jens Mueller wrote:
I'm converting a .h to a d module. I'm following the guide on
http://www.digitalmars.com/d/2.0/htomodule.html
It says
"D has const as a storage class, not a type modifier. Hence, just drop
any const used as a type modifier"
I do not
Andrei Alexandrescu wrote:
On 11/22/10 12:01 PM, Steven Schveighoffer wrote:
On Mon, 22 Nov 2010 12:40:16 -0500, Andrei Alexandrescu
wrote:
On 11/22/10 11:22 AM, Steven Schveighoffer wrote:
You're dodging the question. You claim that if I want to use it as an
array, I use it as an array, i
bearophile wrote:
- Signed unsigned comparison warning: unless D invents some other very good
solution, this warning is a ugly but necessary patch over one hole of the C
language that D too has.
This is bug 259, one of the first issues ever reported in bugzilla.
Can you please stop reporting
Johann MacDonagh wrote:
Mostly OT, what was the rationale for requiring the lock prefix being a
separate statement in inline ASM? NASM and MASM keep it inline with the
statement it affects.
Simplifies the syntax considerably. rep is treated in the same way.
g g wrote:
I just want to say cheers to the GDC team for making D. 2.50(2.49 in the wiki)
work in GCC. Great work
Awesome!
Does it pass the Phobos unit tests?
spir wrote:
On Mon, 22 Nov 2010 21:12:24 -0800
Jonathan M Davis wrote:
If you want, it would be easy to write a simple program that read the .json
output of the compiler, and then enforce any naming convention you need.
That could be a useful tool. And I do think that a basic set of "typical
bearophile wrote:
Don:
Since the probability of actually generating a
zero is 1e-4000, it shouldn't affect the speed at all .
If bits in double have the same probability then I think there is a much higher
probability to hit a zero, about 1 in 2^^63, and I'm not counting NaNs (but
tn wrote:
tn Wrote:
int [] 271
int [) 271
int (] 283
int () 285
long [] 372
long [) 399
long (] 401
long () 397
float[] 286
float[) 374
float(]5252
float()5691
double []
spir wrote:
On Mon, 22 Nov 2010 10:14:03 +0100
Don wrote:
Tomek Sowiński wrote:
Don napisał(a):
The efficiency issues are important, but are not the primary motivation.
toString() is just wrong. The idea that there is ONE AND ONLY ONE
textual representation of an object, is, frankly
Tomek Sowiński wrote:
Don napisał(a):
The efficiency issues are important, but are not the primary motivation.
toString() is just wrong. The idea that there is ONE AND ONLY ONE
textual representation of an object, is, frankly, idiotic.
I always thought of toString() as an aid in debugging
spir wrote:
On Sun, 21 Nov 2010 18:21:48 +0100
Don wrote:
spir wrote:
On Sun, 21 Nov 2010 03:17:57 -0800
Jonathan M Davis wrote:
You're not losing _anything_ out of the deal except that you wouldn't do
obj.toString(). Instead you'd do to!string(obj).
I'm usuall
Matthias Walter wrote:
Hi all,
as it seems, the current version of BigInt is not capable of const, i.e.
BigInt(1) + const(BigInt)(1) does not work.
Is there already an effort to fix this or would it make sense if I had
taken some time to create a fix for it? I have no idea of all the asm in
the
spir wrote:
On Sun, 21 Nov 2010 03:17:57 -0800
Jonathan M Davis wrote:
You're not losing _anything_ out of the deal except that you wouldn't do
obj.toString(). Instead you'd do to!string(obj).
I'm usually not using toString(), it's supported by the language. What about
format("%s:%s", a,b)?
Andrei Alexandrescu wrote:
On 11/18/10 1:25 PM, Don wrote:
Steven Schveighoffer wrote:
On Thu, 18 Nov 2010 15:13:19 -0500, Don wrote:
Lars T. Kyllingstad wrote:
First of all, I think Andrei has already implemented this in the
write*() functions. I use this toString() style also for
Steven Schveighoffer wrote:
On Thu, 18 Nov 2010 15:13:19 -0500, Don wrote:
Lars T. Kyllingstad wrote:
First of all, I think Andrei has already implemented this in the
write*() functions. I use this toString() style also for
std.complex.Complex, and I can print complex numbers no problem
Lars T. Kyllingstad wrote:
First of all, I think Andrei has already implemented this in the write*()
functions. I use this toString() style also for std.complex.Complex, and
I can print complex numbers no problem.
Really? It doesn't work for me.
import std.complex;
import std.stdio;
void ma
Sean Kelly wrote:
Walter Bright Wrote:
Russel Winder wrote:
At the heart of all this is that programmers are taught that algorithm
is a sequence of actions to achieve a goal. Programmers are trained to
think sequentially and this affects their coding. This means that
parallelism has to be ex
Andrei Alexandrescu wrote:
On 11/11/10 5:59 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Let me ask a related question: if there were a priority list of things
that Walter should be busy with, where would this feature be on that
list?
For once, I agree with Bearophile. The adjacent str
Manfred_Nowak wrote:
Don wrote:
that's the only thing that is missing
Disagreed.
One of the main points of all languages is to emphasize ones aim,
espacially if there is a chance of misinterpretation because of the
language.
Example: there is only a tiny change in the characters
Rainer Deyke wrote:
On 11/10/2010 19:34, bearophile wrote:
Do you seen anything wrong in this code? It compiles with no errors:
enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
static assert(data[4] == "yellow");
void main() {}
Yet that code asserts.
Wait, what? That's a
so wrote:
Sean took all the code he had written. The other minor contributors
did not yet give permission for their code to be used, so of course it
could not be included.
This is the single big thing on this tango vs phobos issue i never
understand.
What are the reasons/motives behind this o
Jacob Carlborg wrote:
On 2010-11-09 17:43, Andrei Alexandrescu wrote:
I wouldn't be surprised if Tango chose to turn away from compatibility
for the second time (be it theoretical compatibility for now since there
is no Tango for D2). The technical reasons are dwindling and became
tenuous to arg
If anyone would like to use the latest compiler release, but cannot
because of a compiler regression, please specify which bug is the
blocker (and whether you are using D1 or D2).
I'll try to get any such compiler regressions fixed in the next release.
Michel Fortin wrote:
On 2010-11-07 01:41:47 -0500, Don said:
The guarantee of independence is the most important feature. From a
performance point of view, the big win 'pure' gives you comes from
memory management. All memory allocation can be done using a
thread-local memory p
Jonathan M Davis wrote:
On Saturday 06 November 2010 07:42:52 Don wrote:
Michel Fortin wrote:
On 2010-11-05 21:32:47 -0400, Don said:
The motivation for wanting to ban them is to prevent the optimiser
from generating bad code.
It seems to me that disabling pure optimizations inside 's
Michel Fortin wrote:
On 2010-11-05 21:32:47 -0400, Don said:
The motivation for wanting to ban them is to prevent the optimiser
from generating bad code.
It seems to me that disabling pure optimizations inside 'static this()'
would be enough to prevent generating bad code. It&
bearophile wrote:
Don:
Pure functions are allowed to read immutable global variables.
Currently, this even includes globals which are initialized from inside
'static this()'.
Here's an example of how this can be a problem:
immutable int unstable;
pure int buggy() {
bearophile wrote:
J. M. Berger:
Consider immutable type immutable T:
immutable T] a = new immutable T[4];
... time goes by ...
T[1] = foo;
T[3] = bar;
In other words I create an array that I mean to fill in later,
because I don't have meaningful data for it in advance. How do I do
th
Pure functions are allowed to read immutable global variables.
Currently, this even includes globals which are initialized from inside
'static this()'.
Here's an example of how this can be a problem:
immutable int unstable;
pure int buggy() { return unstable; }
static this() {
// fails ev
Pelle Månsson wrote:
On 11/05/2010 03:04 PM, Kagamin wrote:
Pelle Månsson Wrote:
Getting the error early is actually a lot better than getting the error
late.
OK, but it doesn't reduce the number of bugs. You had an error with
nullables and you still has error with non-nullables.
But in t
801 - 900 of 2058 matches
Mail list logo
