Walter Bright wrote:
Nick Sabalausky wrote:
To put it simply, I agree with this even on mere principle. I'm
convinced that the current D behavior is a blatant violation of
strong-typing and smacks way too much of C's so-called "type system".
You're certainly not the first to feel this way abo
Andrei Alexandrescu wrote:
On 03/23/2010 04:06 PM, grauzone wrote:
Steven Schveighoffer wrote:
A while back, you identified one of the best interfaces for input
ranges:
E* getNext();
Which allows for null returns when no data is left. The drawback is
that E must be either referenced or
Steven Schveighoffer wrote:
A while back, you identified one of the best interfaces for input ranges:
E* getNext();
Which allows for null returns when no data is left. The drawback is
that E must be either referenced or allocated on the heap (providing
storage to the function is an option).
Don wrote:
In D some people have proposed to change the semantics of the "is"
operator, to make it more useful and tidy, so if you want to know if x
is a NaN you can then write if(x is nan).
That won't work in this case, unless you make nan a keyword. There are
2^^62 different NaNs, so a bitwis
bearophile wrote:
Andrew Marlow:
Well, thanks for that, at least I know now. But I am a bit peeved. What is the
point in calling something 'std' if it is not standard. I am used to 'std'
meaning 'it comes with the compiler environment'.
Please, ask questions like those ones on the learn news
Walter Bright wrote:
Currently, given an array:
alias T[3] A;
A a;
the default initializer for A, A.init, is T.init. It is done this way
for memory efficiency, as:
a = A.init;
doesn't need to create an array for the rvalue. But it does cause
generic programming problems, especiall
Walter Bright wrote:
The fact is, people *do* have major problems with concurrent
programming. Sharing of mutable state is a large generator of these
problems, and I don't think we can wish it away or blame the programmer.
I didn't advocate sharing of mutable state.
Walter Bright wrote:
grauzone wrote:
Data this small you would simply copy. Because it's so small, copying
won't have negative performance impact. The OS approach can be used
for large data (at least in the order of hundreds of KB) and immutable
parts of the data segment.
You'
Andrei Alexandrescu wrote:
On 03/10/2010 07:07 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 06:47 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 06:06 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 05:01 PM, grauzone wrote:
Andrei Alexandrescu
Andrei Alexandrescu wrote:
On 03/10/2010 06:47 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 06:06 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 05:01 PM, grauzone wrote:
Andrei Alexandrescu wrote:
There's one final nail in the coffin. In wake of concur
Andrei Alexandrescu wrote:
On 03/10/2010 06:06 PM, grauzone wrote:
Andrei Alexandrescu wrote:
On 03/10/2010 05:01 PM, grauzone wrote:
Andrei Alexandrescu wrote:
There's one final nail in the coffin. In wake of concurrency, de jure
immutability becomes a necessity, not a useful and desi
Andrei Alexandrescu wrote:
The kick-off meeting for Thunderbird 3:
"Thunderbird 2 is quite sluggish, has poor asynchronous execution of
tasks, poor focus control, and annoying modal dialogs on error. What do
we do for version 3?"
...
The main reason why I went back to Thunderbird 2 is that
Andrei Alexandrescu wrote:
On 03/10/2010 05:01 PM, grauzone wrote:
Andrei Alexandrescu wrote:
There's one final nail in the coffin. In wake of concurrency, de jure
immutability becomes a necessity, not a useful and desirable de facto
convention. Adopting the window dressing but not the es
Ellery Newcomer wrote:
I hate the restriction on modules with static constructors and cyclic
dependencies. IMO it's the most patronizing 'feature' D has. A year or
so ago I ran into this issue during my first (and last) big project in
D. Just last week I started working on it again and replaced
Andrei Alexandrescu wrote:
There's one final nail in the coffin. In wake of concurrency, de jure
immutability becomes a necessity, not a useful and desirable de facto
convention. Adopting the window dressing but not the essence of FP by a
concurrent language evokes to me a scene in the Marx Bro
Walter Bright wrote:
grauzone wrote:
Again, I can't understand. Does the compiler rely that tuples have the
same byte layout as structs or function arguments? I thought the
compiler could just copy all fields. And the backend can already
return multiple values, since it can return struct
bearophile wrote:
grauzone:
That aside, I'm also glad that you acknowledge that current tuples are
not perfect and need improvement.
I agree.
It's probably already too late to fix them,<
It isn't.
D2 is pretty much finalized now. The discussion (i.e. bikeshedding)
Walter Bright wrote:
grauzone wrote:
Walter Bright wrote:
bearophile wrote:
Walter Bright:
There are significant technical problems with having functions
return tuples.<
A possibly stupid question: isn't it enough to return a custom struct?
No, because of the alignment mismatc
Lutger wrote:
Michael Rynn wrote:
That IS what Walter thinks, actually. It's being moved to libraries
(which is why there have been some nasty AA regressions in the past few
compiler releases :-( ).
Sounds good. So the source is in druntime?
Does that mean I can find out how to implement opIn
Walter Bright wrote:
bearophile wrote:
Walter Bright:
There are significant technical problems with having functions return
tuples.<
A possibly stupid question: isn't it enough to return a custom struct?
No, because of the alignment mismatches with other uses of tuples.
I don't understand
Walter Bright wrote:
bearophile wrote:
Walter Bright:
Yeah, I wrote a C++ compiler back in 1987. It compiled itself, too!
The hard work of implementing C++ correctly was just beginning,
though.
C'mon Walter, give them some credit, wish them some luck, I think
they will be able to compile a go
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 12:43:32 -0500, grauzone wrote:
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone wrote:
Some sort of "resetAndReuse" function to clear an array, but
enabling to reuse the old memory would be nice:
int[] a
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone wrote:
Some sort of "resetAndReuse" function to clear an array, but enabling
to reuse the old memory would be nice:
int[] a = data;
a = null;
a ~= 1; //reallocates (of course)
a.length = 0;
a ~= 1; //will
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 04:02:46 -0500, KF wrote:
I hope this is the right place to post it.
In my work, I often need to add elements at the end of dynamic arrays
and remove them from the end. This incremental changes would most
conveniently be performed by a~=e for ad
bearophile wrote:
grauzone:
Apparently, this attribute syntax makes no sense at all. I suggest we
simply remove it and use normal keywords instead.
Currently D2 attributes are not necessary, they can be replaced by keywords,
but keywords don't scale if you want to define many new attr
Don wrote:
We'll need compile-time reflection for all attributes. This can lead us
to a rationale for which attributes are keywords, and which are
@attributes.
Apparently, this attribute syntax makes no sense at all. I suggest we
simply remove it and use normal keywords instead.
Steven Schveighoffer wrote:
Don wants to make array literals immutable; that means you couldn't
just assign them to int[] anyway. In both cases, you'd have to use
.dup to use them as normal, mutable arrays.
That's fine, if I don't specify dup by accident, the compiler would
complain. In Deni
Steven Schveighoffer wrote:
On Thu, 18 Feb 2010 20:47:16 -0500, Denis Koroskin <2kor...@gmail.com>
wrote:
On Fri, 19 Feb 2010 00:46:05 +0300, Steven Schveighoffer
wrote:
That would be bad, T[] is implicitly casted from T[N]. Consider
that you could easily escape stack data using this. In
Don wrote:
grauzone wrote:
IMHO array literals should be static arrays, which are value types. No
issues with heap allocation or immutability requirements.
That still wouldn't solve the performance problems.
You mean even for a static array on the stack, the time to construct it
IMHO array literals should be static arrays, which are value types. No
issues with heap allocation or immutability requirements.
Also, even immutable values can change at runtime:
void foo(immutable int x) {
auto array = [x];
}
array would have needed to be heap allocated even if they
retard wrote:
Tue, 16 Feb 2010 21:11:32 +0100, grauzone wrote:
retard wrote:
Granted, even if logging is disabled, the compiler will push the
arguments on the stack and call logInfo().
This is a case where a JIT compiler wins. The code runs equally fast
without the call at all and with
retard wrote:
Granted, even if logging is disabled, the compiler will push the
arguments on the stack and call logInfo().
This is a case where a JIT compiler wins. The code runs equally fast
without the call at all and with logging turned off (dynamically). In
languages like D, the like has t
Nick Sabalausky wrote:
"grauzone" wrote in message
news:hlbg22$6f...@digitalmars.com...
Nick Sabalausky wrote:
"BCS" wrote in message
news:a6268ff103d38cc7ba48d6fa...@news.digitalmars.com...
Hello Nick,
I *definitely* want that for string mixins of both the
templat
bearophile wrote:
I have shown this little program to some of my friends that program in Java/C#:
class Foo {
private int x;
}
void main() {
Foo f = new Foo;
f.x = 5;
}
When I say them this code compiles with D2 they usually tell me that the
compiler has a bug.
So I suggest Walter
Steven Schveighoffer wrote:
On Sun, 14 Feb 2010 18:28:38 -0500, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
On Mon, 15 Feb 2010 00:31:29 +0300, Walter Bright
wrote:
Right now, mixins are defined and used as:
template foo(T) { declarations... }
mixin foo!(int) handle;
The p
dsimcha wrote:
2. Pointer offset information for each type is determined at compile time using
template metaprogramming.
Why don't you just ask Walter to make dmd generate the necessary
information?
Nick Sabalausky wrote:
"BCS" wrote in message
news:a6268ff103d38cc7ba48d6fa...@news.digitalmars.com...
Hello Nick,
I *definitely* want that for string mixins of both the
template-generated and ctfe-generated varieties.
Why? I don't see any reason aside from documentation to do it.
Well,
Andrei Alexandrescu wrote:
Michel Fortin wrote:
On 2010-02-14 15:41:30 -0500, Andrei Alexandrescu
said:
Michel Fortin wrote:
Hum, what's the syntax for placement delete?
There is no need for placement delete. There will be a function
clear() in object.d that only calls the destructor. (
Lars T. Kyllingstad wrote:
Andrei Alexandrescu wrote:
Gone, that is. Walter agreed to remove it.
To achieve the functionality of
foreach_reverse (r) { ... }
use
foreach (retro(r)) { ... }
using retro in std.range.
Now all what's left to do is to make it as efficient as the builtin
functi
Andrei Alexandrescu wrote:
Traits indeed offer more than interfaces. We're looking at sensible
things to do within the time constraints we're having; traits would be a
major effort, whereas methods in interfaces are just eliminating an
artificial limitation. Traits are a possible addition to D3
Walter Bright wrote:
retard wrote:
I can easily come up with 100 other such features.
Please do so, and submit them to bugzilla.
You know, the problem with Bugzilla is, that most entries simply remain
unreplied. Especially when they inquire about strange language features
or dark corner ca
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
Don wrote:
I suspect that string, wstring should have been the primary types and
had a .codepoints property, which returned a ubyte[] resp. ushort[]
reference to the data. It's too late, of course. The extra value you get
by having a specific type
Andrei Alexandrescu wrote:
What can be done about that? I see a number of solutions:
(a) Do not operate the change at all.
(b) Operate the change and mention that in range algorithms you should
check hasLength and only then use "length" under the assumption that it
really means "elements coun
Andrei Alexandrescu wrote:
Steve Teale wrote:
Walter Bright Wrote:
Steve Teale wrote:
Are we still just talking just AMD 64 here? Last time I tried to
install the .deb package, the system told m that my Intel core2 64
bit machine was the wrong architecture.
Yes, I have an AMD64. How that woul
Don wrote:
grauzone wrote:
Jason House wrote:
Andrei's finishing his last TDPL chapter, Sean is updating
std.thread(?), and Walter's been fixing forward reference and CTFE
bugs. What's left?
Documentation. The Phobos docs are rather bad, and don't even include
th
Simen kjaeraas wrote:
On Sun, 24 Jan 2010 15:12:47 +0100, grauzone wrote:
Eldar Insafutdinov wrote:
grauzone Wrote:
Eldar Insafutdinov wrote:
Andrei Alexandrescu Wrote:
Eldar Insafutdinov wrote:
Jesse Phillips Wrote:
Jason House wrote:
Andrei's finishing his last TDPL chapter,
Jason House wrote:
Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and Walter's been fixing forward reference and CTFE bugs. What's left?
Documentation. The Phobos docs are rather bad, and don't even include
the core modules. Also there's std.thread, shouldn't it be c
Eldar Insafutdinov wrote:
grauzone Wrote:
Eldar Insafutdinov wrote:
Andrei Alexandrescu Wrote:
Eldar Insafutdinov wrote:
Jesse Phillips Wrote:
Jason House wrote:
Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and Walter's been fixing forward referenc
Andrei Alexandrescu wrote:
grauzone wrote:
Adam D. Ruppe wrote:
On Sat, Jan 23, 2010 at 12:00:04PM -0500, Steve Teale wrote:
I see that Go has now usurped D's former place at #13 in Tiobe -
which I realize of course does not mean anything. But I'd be
interested to hear what the D a
Eldar Insafutdinov wrote:
Andrei Alexandrescu Wrote:
Eldar Insafutdinov wrote:
Jesse Phillips Wrote:
Jason House wrote:
Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and Walter's been fixing forward reference and CTFE bugs. What's left?
This page[1] has been ge
dsimcha wrote:
Multiple return values are a horrible substitute for exceptions, because they
require the programmer to explicitly check the return value. (When's the last
time you checked the return value of printf, or even malloc?) IMHO the best
thing
about exceptions is that they provide a s
Adam D. Ruppe wrote:
On Sat, Jan 23, 2010 at 12:00:04PM -0500, Steve Teale wrote:
I see that Go has now usurped D's former place at #13 in Tiobe - which I
realize of course does not mean anything. But I'd be interested to hear what
the D aficionados think of Go.
There's been a couple threads
Nick Sabalausky wrote:
"Nick Sabalausky" wrote in message
news:hjff0j$27i...@digitalmars.com...
- Does nothing to change my opinion that Google has done nothing
noteworthy outside of search engines and maybe their ad service.
And their maps, of course. But then again, how google, of all com
Steven Schveighoffer wrote:
On Wed, 13 Jan 2010 06:28:33 -0500, Jacob Carlborg wrote:
On 1/12/10 23:40, Walter Bright wrote:
It's true that nobody has spent the effort to do this. Anyone is welcome
to step up and work on it.
Hasn't that already been solved with ddl:
http://www.dsource.org/
Sean Kelly wrote:
Don Wrote:
I once had a customer make a request for a very small DOS utility
program, and specifically said that they didn't have much disk space
left on their computer, could I please make sure the executable wasn't
too big?
I wrote it in asm. It was 15 bytes.
Hah. You
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
The idea is that the API offers a means to define and use
temporary buffers without compromising memory safety. Even if you
escape
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
The idea is that the API offers a means to define and use temporary
buffers without compromising memory safety. Even if you escape data
allocated via getBuffer that persists
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
The idea is that the API offers a means to define and use temporary
buffers without compromising memory safety. Even if you escape data
allocated via getBuffer that persists after releaseBuffer, that will
not cause
Brad Roberts wrote:
On 1/11/2010 11:20 PM, grauzone wrote:
g wrote:
Hi
Is there a way to demangle .mangleof strings at CTFE
or at least know the fully qualified name of a class or template
instance.
If you have to use such dirty tricks, you probably should consider to
turn back NOW for your
Andrei Alexandrescu wrote:
The idea is that the API offers a means to define and use temporary
buffers without compromising memory safety. Even if you escape data
allocated via getBuffer that persists after releaseBuffer, that will not
cause undefined behavior. (It may, however, cause data to b
bearophile wrote:
dsimcha:
Struct constructors are D2 only. That said, you can fake them in D1 by
overloading static opCall:
Struct constructors are probably the D2 feature I miss more in D1 :-)
Why?
Bye,
bearophile
g wrote:
Hi
Is there a way to demangle .mangleof strings at CTFE
or at least know the fully qualified name of a class or template instance.
If you have to use such dirty tricks, you probably should consider to
turn back NOW for your own good. D always lures you into doing tricky
template and
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
bearophile wrote:
void bar(int n) {
scope int[] a = new int[n]; // stack-allocated
foo(a);
}
Why are you making such proposals, when one of the core
bearophile wrote:
grauzone:
Why are you making such proposals, when one of the core developers even
thought about removing normal "scope"?
And by the way, in the Python community one of the purposes of PEPs is to act
as an archive of refused proposals, so people can avoid was
Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
bearophile wrote:
void bar(int n) {
scope int[] a = new int[n]; // stack-allocated
foo(a);
}
Why are you making such proposals, when one of the core developers
even thought about removing normal
Andrei Alexandrescu wrote:
grauzone wrote:
bearophile wrote:
void bar(int n) {
scope int[] a = new int[n]; // stack-allocated
foo(a);
}
Why are you making such proposals, when one of the core developers
even thought about removing normal "scope"? It's almost 100%
guarant
Walter Bright wrote:
If you want to know where the size in your exe file is coming from, the
map file will tell you - broken down by each name and its associated size.
Can you tell me how many bytes all TypeInfos use up in libphobos?
(Without disabling codegen for TypeInfos and comparing the fi
bearophile wrote:
void bar(int n) {
scope int[] a = new int[n]; // stack-allocated
foo(a);
}
Why are you making such proposals, when one of the core developers even
thought about removing normal "scope"? It's almost 100% guaranteed that
nobody will listen.
I personally find it a good id
Nick Sabalausky wrote:
I'd rather use an app that did a bunch of compile-time reflection than one
that did a bunch of run-time reflection. And I think that 50..100 MB figure
The question is: what will cause more overhead? Compile time or runtime
reflection? For some use cases, you'll have com
Walter Bright wrote:
grauzone wrote:
Walter Bright wrote:
grauzone wrote:
(The final executable is almost twice the size as the D2 one too,
although it's questionable how much of the additional size is due to
templates.)
Finding out why an executable is large is as easy as compiling
Walter Bright wrote:
grauzone wrote:
(The final executable is almost twice the size as the D2 one too,
although it's questionable how much of the additional size is due to
templates.)
Finding out why an executable is large is as easy as compiling with
-L/map on Windows and -L-map -Lfo
Nick Sabalausky wrote:
"Ph" wrote in message
news:hia7qc$b5...@digitalmars.com...
Why a generated file is so huge?
"Empty" program such as:
int main(char[][] args)
{
return 0;
}
compiled with dmd2 into file with size of 266268 bytes.
Even after UPX, it's size is 87552 bytes.
Size of this co
Walter Bright wrote:
grauzone wrote:
Walter Bright wrote:
retard wrote:
Fri, 01 Jan 2010 12:19:25 -0800, Walter Bright wrote:
When I then picked up K+R C, I never wrote another line of Pascal.
It so
soured me on Pascal that I never got on the later bandwagons of Modula
II, Delphi
Walter Bright wrote:
retard wrote:
Fri, 01 Jan 2010 12:19:25 -0800, Walter Bright wrote:
When I then picked up K+R C, I never wrote another line of Pascal. It so
soured me on Pascal that I never got on the later bandwagons of Modula
II, Delphi, TurboPascal, etc. Never even looked at them.
The
Andrei Alexandrescu wrote:
bearophile wrote:
I don't know C++ much, and I have to confess that I have to fully
understand the const business still. I hope your book will teach me
this topic very well :-)
One thing about const that is slowly downing on this community is that
it will _not_ be
justme wrote:
grauzone Wrote:
bearophile wrote:
BCS:
A though on the comma operator: if the comma operator were
defined to give a tuple type and be implicitly castable to any
suffix of it's self, then you could get both the comma
expression usage that Walter wants as well as all th
bearophile wrote:
BCS:
A though on the comma operator: if the comma operator were defined to give
a tuple type and be implicitly castable to any suffix of it's self, then
you could get both the comma expression usage that Walter wants as well as
all the fun things that tuple expressions give.
BCS wrote:
Hello justme,
bearophile Wrote:
C# will probably not follow the route of stagnation of Java for some
more time, thanks to Mono too. I don't like that string interpolation
syntax because it looks unsafe, and that design of tuples can be
improved, but they are listening to programmes
grauzone wrote:
justme wrote:
grauzone Wrote:
justme wrote:
bearophile Wrote:
C# will probably not follow the route of stagnation of Java for
some more time, thanks to Mono too. I don't like that string
interpolation syntax because it looks unsafe, and that design of
tuples c
justme wrote:
grauzone Wrote:
justme wrote:
bearophile Wrote:
C# will probably not follow the route of stagnation of Java for some more time,
thanks to Mono too. I don't like that string interpolation syntax because it
looks unsafe, and that design of tuples can be improved, but the
revcompgeek wrote:
So I tried building Tango trunk a while ago, and it actually built
surprisingly well, with only one small error I was able to fix. So I
installed the tango library and proceeded to test if tango was really
working. So in hello.d:
import tango.io.Stdout;
void main(){ Stdout("H
justme wrote:
bearophile Wrote:
C# will probably not follow the route of stagnation of Java for some more time,
thanks to Mono too. I don't like that string interpolation syntax because it
looks unsafe, and that design of tuples can be improved, but they are listening
to programmes (even if
Walter Bright wrote:
grauzone wrote:
It matters because Java is used a lot in multithreaded applications,
and it is gc based. The gc is not a disastrous problem with it.
For one, Java has an infinitely better GC implementation than D. Yeah,
this isn't a problem with the concept o
Walter Bright wrote:
grauzone wrote:
Also, it's bad how inter-thread communication will trigger GC runs,
No, it won't. Allocation may trigger a GC run.
which will stop all threads in the process for a while. Because you
have no choice but to allocate your immutable messages from
Steven Schveighoffer wrote:
Also, if you use GC.malloc directly, and the user tries to append to
slices to it, your code may break. GC.malloc doesn't seem to pad the
memory block with a length field.
Yes, this is a possible problem. However, using GC.malloc directly and
then treating the res
Walter Bright wrote:
grauzone wrote:
What will you do?
Because of casting, there cannot be a thread-local only gc.
I think this is a very bad idea. I thought TLS by default was just the
beginning of separating threads better. While it will work in the
initial stages of D2, I don't
Steven Schveighoffer wrote:
I see no problem with adding an additional field to usual slices.
There's also some benefit: clearer semantics (if you make guaranteed
performance part of the semantics) and a much simpler runtime.
Simpler runtime is not any benefit IMO. Nobody cares how array appe
Walter Bright wrote:
But you need to allocate this data from a shared garbage collection,
You do anyway.
Consider you allocate normal data from a thread local heap, and shared
data from a shared GC. We will need this anyway to get decent memory
allocation and GC performance. Especially beca
Steven Schveighoffer wrote:
grauzone Wrote:
Steven Schveighoffer wrote:
The problem is that adding a capacity field only works if the object is a
reference type. A value type will make either choose to make copies of the
capacity field, resulting in the same stomping problem (and maybe
Walter Bright wrote:
3. (2) has a great advantage in doing message passing between
threads. This model was popularized by Erlang, and is very
successful. You can do message passing without immutable references,
but you've got to hope and pray that your programming team didn't
make any mistakes
Walter Bright wrote:
grauzone wrote:
Walter Bright wrote:
I can expound on the huge advantages immutability and purity offer,
if you want.
Yes, I'd like to hear about this. You can leave away the things that
are not going to be implemented (like memorization of pure return
values)
Andrei Alexandrescu wrote:
grauzone wrote:
Steven Schveighoffer wrote:
All,
I created a new patched druntime that prevents array stomping and at
the same time increases append performance for thread-local array
appending.
The patch is attached to bugzilla entry 3637. (
http
Steven Schveighoffer wrote:
grauzone Wrote:
Steven Schveighoffer wrote:
All,
I created a new patched druntime that prevents array stomping and at the
same time increases append performance for thread-local array appending.
The patch is attached to bugzilla entry 3637. (
http
Steven Schveighoffer wrote:
All,
I created a new patched druntime that prevents array stomping and at the
same time increases append performance for thread-local array appending.
The patch is attached to bugzilla entry 3637. (
http://d.puremagic.com/issues/show_bug.cgi?id=3637 )
Nobody car
Walter Bright wrote:
I can expound on the huge advantages immutability and purity offer, if
you want.
Yes, I'd like to hear about this. You can leave away the things that are
not going to be implemented (like memorization of pure return values),
are only micro-optimizations (common sub-expres
Walter Bright wrote:
Yigal Chripun wrote:
But that doesn't mean the idea itself isn't valid. Perhaps a different
language with different goals in mind can provide a much simpler non
convoluted implementation and semantics for the same idea?
You've shown in the past that you're willing to break
Andrei Alexandrescu wrote:
But let's not forget we have concurrency ahead of us. I encourage you
all to chime in with your thoughts and ideas regarding all aspects of
concurrency. The recent multicore performance bug is a great starting
point. If you try e.g. shared and it's broken, let us know
Andrei Alexandrescu wrote:
retard wrote:
Most likely Walter won't even tell what kind of arrays D2 will have.
Anything can happen. The final word is the undocumented executable you
can download when the book hits stores.
That's a bit of an oxymoron isn't it :o). The book _is_ the
documentati
Nick Sabalausky wrote:
"Ellery Newcomer" wrote in message
It's a useful divergence. It's a feature that should exist. But I contend
it makes more sense to make a new construct which *is* equivalent to a
certain pattern of nested ifs (switch isn't) and incorporate your feature
into that than t
Andrei Alexandrescu wrote:
Bill Baxter wrote:
On Mon, Nov 30, 2009 at 7:12 PM, Walter Bright
wrote:
Bill Baxter wrote:
So we can overload on @property-ness?
No.
I.e. this works
struct S
{
@property
float x() { return 1.0f; }
float x() { return 2.0f; }
}
void main()
{
S s;
writefln
1 - 100 of 492 matches
Mail list logo
