On Thursday, 5 December 2013 at 13:55:30 UTC, Martin Nowak wrote:
Ah well, this was a question for ideas.
I don't really know to get there.
I can think of a few things:
1. The compiler could mark what made it reject a candidate. If it
failed due to a template constraint it could flag the last
Bloomberg released an STL alternative called BSL which contains
an alternate allocator model. In a nutshell object supporting
custom allocators can optionally take an allocator pointer as an
argument. Containers will save the pointer and use it for all
their allocations. It seems simple enough
On Wednesday, 12 June 2013 at 06:08:58 UTC, deadalnix wrote:
We currently have a problem with containers : it is very
difficult to implement them in a way that is compliant type
qualifiers. To restate the problem shortly, let's imagine we
want to implement array's as a library type.
struct
On Thursday, 3 January 2013 at 05:56:27 UTC, Timon Gehr wrote:
On 01/03/2013 12:48 AM, Jason House wrote:
...
ref int bar()
{
int i = 7;
return foo(i);
}
If @safe, this code will not compile.
Error: foo may return a local stack variable
Since i is a local variable, foo(i) might
On Sunday, 30 December 2012 at 08:38:27 UTC, Jonathan M Davis
wrote:
After some recent discussions relating to auto ref and const
ref, I have come
to the conlusion that as it stands, ref is not @safe. It's
@system. And I
think that we need to take a serious look at it to see what we
can do to
On Thursday, 3 January 2013 at 00:59:04 UTC, Walter Bright wrote:
As always, when I try to do a release, problems crop up. For
example,
the github procedure agreed upon and outlined here:
http://wiki.dlang.org/Proposed_new_D_development_process#Release_a_new_version_of_D
Issues:
1. you
On Thursday, 29 November 2012 at 02:34:11 UTC, Walter Bright
wrote:
For discussion:
Cyclical Imports
Problem:
a.d
module a;
import b;
static this () { ... }
b.d
module b;
import a;
static this() { ... }
-
Static constructors for a
On Monday, 19 November 2012 at 04:57:16 UTC, deadalnix wrote:
Le 17/11/2012 05:49, Jason House a écrit :
On Thursday, 15 November 2012 at 16:31:43 UTC, Sean Kelly
wrote:
On Nov 11, 2012, at 6:30 PM, Walter Bright
newshou...@digitalmars.com wrote:
To make a shared type work in an algorithm
On Thursday, 15 November 2012 at 16:31:43 UTC, Sean Kelly wrote:
On Nov 11, 2012, at 6:30 PM, Walter Bright
newshou...@digitalmars.com wrote:
To make a shared type work in an algorithm, you have to:
1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the
On Monday, 12 November 2012 at 02:31:05 UTC, Walter Bright wrote:
To make a shared type work in an algorithm, you have to:
1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5. release the mutex
This is a fairly reasonable
On Thursday, 2 August 2012 at 04:48:56 UTC, Walter Bright wrote:
On 8/1/2012 9:41 PM, H. S. Teoh wrote:
Whether it's part of the range type or a separate lexer type,
*definitely* make it possible to have multiple instances. One
of the
biggest flaws of otherwise-good lexer generators like lex
On Monday, 4 June 2012 at 11:17:45 UTC, Michel Fortin wrote:
After trying to make sense of the thread synchronized
(this[.classinfo]) in druntime and phobos, I had to write my
opinion on all this somewhere that wouldn't be instantly lost
in a bazilion of posts. It turned out into something
On Monday, 4 June 2012 at 17:40:38 UTC, Michel Fortin wrote:
On 2012-06-04 13:15:57 +, Jason House
jason.james.ho...@gmail.com said:
If you really want to use synchronized classes, then you should
have two of them.
Valid comment. I thought about creating yet another example
On Monday, 5 March 2012 at 04:39:59 UTC, Adam D. Ruppe wrote:
Huh, I thought there was one in phobos by now.
You could spin your own with something like this:
struct NotNull(T) {
T t;
alias t this;
@disable this();
@disable this(typeof(null));
this(T value) {
assert(value !is
On Friday, 17 February 2012 at 02:49:40 UTC, Walter Bright wrote:
Given:
class A { void foo() { } }
class B : A { override pure void foo() { } }
This works great, because B.foo is covariant with A.foo,
meaning it can tighten, or place more restrictions, on foo.
But:
class A {
On Thursday, 23 February 2012 at 19:48:11 UTC, deadalnix wrote:
Le 23/02/2012 18:27, Andrei Alexandrescu a écrit :
http://www.reddit.com/r/programming/comments/q2pmd/inheriting_purity_in_the_d_programming_language/
Andrei
I'm still not convinced by const (this can lead to very
confusing
On Thursday, 23 February 2012 at 17:10:58 UTC, Bruno Medeiros
wrote:
Sounds like a good idea.
I would even add to this that it might be useful to have
similar syntax that would allow to define an override method
without having to specify the return type nor the parameters of
the overridden
Timon Gehr Wrote:
On 12/05/2011 02:16 AM, Graham St Jack wrote:
What is the status of the immutable(Object) ref proposal? Is it on the
list of things to do, or is it ruled out? If it is ruled out, then what
is the superior proposal?
It is not fully implemented and apparently Walter
Jesse Phillips Wrote:
On Tue, 29 Nov 2011 20:34:51 -0500, bearophile wrote:
A recently written report from a firm that has switched back from Scala
to Java:
https://raw.github.com/
gist/1406238/72ade1a89004a9a7d705b00cfd14b90b2b6a26bd/gistfile1.txt
Interesting.
The main key
Sean Kelly Wrote:
There's another important issue that hasn't yet been addressed, which is that
when the GC collects memory, the thread that finalizes non-shared data should
be the one that created it. So that SHARED flag should really be a thread-id
of some sort. Alternately, each thread
Sean Kelly Wrote:
On Oct 3, 2011, at 3:27 PM, Jason House wrote:
Sean Kelly Wrote:
There's another important issue that hasn't yet been addressed, which is
that when the GC collects memory, the thread that finalizes non-shared
data should be the one that created it. So that SHARED
Mehrdad Wrote:
On 9/23/2011 11:47 AM, Jonathan M Davis wrote:
...You'd have to duplicate functions all over the place... - Jonathan
M Davis
Can't you avoid that trivially with templates?
While templates can be used to coerce a lot of similar things together, it's
rarely done without
std.algorithm already introduces a sort of lambda syntax...
map!a+b(...) or map!q{a+b}(...)
If D is looking for its own style of short lambda, maybe implicit use of a and
b could be extended.
Candidates:
a+b
{a+b}
f{a+b}
auto{a+b}
auto a+b
Personally, I like the 2nd or 3rd one. The second is
bearophile Wrote:
With the latest DMD versions it's easy to create an immutable array of
structs, with a pure function (I think this gives advantages similar to the
Transients of the Clojure language):
...
Two alternate ideas:
1. Reserve the required space then start appending
2. Use a
Timon Gehr Wrote:
On 09/08/2011 03:07 PM, Jason House wrote:
bearophile Wrote:
With the latest DMD versions it's easy to create an immutable array of
structs, with a pure function (I think this gives advantages similar to
the Transients of the Clojure language):
...
Two
The post says they did dmd -O. They did not mention -inline -noboundscheck
-release. There may be extra flags that are required.
Walter Bright Wrote:
http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98
Anyone care to examine the assembler output and figure out
Loopback Wrote:
On 2011-07-06 16:56, Don wrote:
It's a compiler CTFE bug, which has been fixed in the latest beta
release (2.054).
I am in dire need for the beta release then I guess. Is it any mature,
or what's even more important; where are the download mirrors/the
repository?
Dmd
I wonder a bit why you want one file per object? Is it to avoid unnecessary
imports? Make finding object definitions easier? Or a style preference? I think
replies by others covered all but the first question. I use the import
std.foo: bar, baz; syntax for that.
Generally speaking, separating
Steven Schveighoffer Wrote:
On Fri, 06 May 2011 03:39:31 -0400, Mariusz GliwiÅski
alienballa...@gmail.com wrote:
Is this bug, or is it as supposed to be? I'm not sure...
code
interface TmpI(T) {
void func(T);
}
class TmpC {}
class TmpC2 : TmpC {}
class Tmp :
Misuse of std.parallelism can very easily cause accidental sharing of data.
Both in the interfaces to std.parallelism and inside the code, the whole shared
concept is intentionally side stepped. The only use of shared is when using
atomic operations from druntime that were properly coded.
I
Ashish Myles Wrote:
foo2 = foo; // allowed immutable RHS ???
Allowing this is a bug. File it in bugzilla.
Unfortunately, lazy objects mess up the expected const correctness of Object.
Even if they are logically const, lazy objects can't always be passed as const.
Don Wrote:
Tomek Sowiñski wrote:
I'm far from being a GC expert but I think Java having identified such
cases with escape analysis just puts locally allocated objects on the stack.
That works for the non-leaky function itself, but it doesn't help for
the functions it calls.
It'd reduce
I agree that the output ordering does not make sense. Try altering your example
slightly so the program will segfault or do some other nonsensical thing if
that is truly the order of operations. Once you have that, it'd make a great
bugzilla entry! It definitely looks like a bug to me.
Morlan
Jose Armando Garcia Wrote:
On Wed, Mar 30, 2011 at 9:39 PM, Jason House
jason.james.ho...@gmail.com wrote:
Jose Armando Garcia Wrote:
How do I get around this error?
That's not easy to answer... To get the compiler to shut up, you can copy
and paste FILE's destructor and mark
he compiler wants argument types () shared instead of argument types ().
It's an awful error message, and I'm certain I filed a bug for it at least a
year ago. In the toy example, mark the destructor as shared, and it should
compile.
Jose Armando Garcia Wrote:
It looks like the following
KennyTM~ Wrote:
On Mar 31, 11 06:34, Jason House wrote:
he compiler wants argument types () shared instead of argument types
(). It's an awful error message, and I'm certain I filed a bug for it at
least a year ago. In the toy example, mark the destructor as shared, and it
should
Jose Armando Garcia Wrote:
Why am I getting this error? I suspect that synchronized is the
problem.
A synchronized class is implicitly shared and most of the methods are
synchronized. I say most because at a minimum, the constructor isn't
synchronized on anything. As you probably know
dsimcha Wrote:
I'm thinking about ways to make std.concurrency's model more flexible
without compromising safety. It's sometimes useful to cheaply _move_
(as opposed to share or copy) data between threads. I wonder if we
could co-opt sealed containers here:
What definition of sealed are
Do you require that ThreadsafeLogger is a Logger, or is it ok if
ThreadsafeLogger has a Logger? The latter is trivial to implement.
Benjamin Thaut Wrote:
First thought:
Consider the following code:
import std.concurrency;
class Logger {
void log(string msg){
//do
dsimcha Wrote:
Some discussions about std.parallelism have prompted an examination of
how far D's guarantees against low level data races should extend and
how safety and practicality should be balanced.
I didn't follow the review of std.parallelism, can you give some specific
examples?
Nick Sabalausky Wrote:
These module constructor Cyclic dependencies errors are really starting to
piss me off. I feel like I'm back in the days when you'd sneeze and DMD
would vomit out 100 forward reference errors just because you didn't write
your whole damn app in one giant
Nick Wrote:
Coming from Andrei's work in C++ Modern C++ Programming I wonder how
to implement many of those patterns in D?
In C++ I would work with type lists and use lots of multiple inheritance
and templates to get the magic I need.
I don't have the book, but I'm sure that if you
Sounds promising. How does it effect other cases? Some typical GC-heavy
benchmark? Lots of smaller no scan objects that are just under your
optimization threshold?
dsimcha Wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=5623
I've found a way to speed up the GC massively on large heaps
Vladimir Panteleev Wrote:
int foo;
enum bar = foo+2;
void main()
{
foo = 7;
assert(bar == 9);
}
--
Best regards,
Vladimirmailto:vladi...@thecybershadow.net
I would have expected bar to equal 2 since foo would be default initialized to
2.
Sean Eskapp Wrote:
Has this been reported?
Do what any of us would do... Search bugzilla and that as a bug if you don't
find it.
The very fact that you didn't have issues with size_t before compiling in 64
bit mode seems like a short-coming of D. It should be hard to write code that
isn't platform independent. One would kind of hope that size_t was a distinct
type that could have uints assigned to them without casts. It
Don Wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on everything.
opEquals() is in conflict with this, since it is a member function of
Object.
(1) If it is a const member function, then it will
Steven Schveighoffer Wrote:
On Thu, 10 Feb 2011 09:15:36 -0500, Jason House
jason.james.ho...@gmail.com wrote:
Don Wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything
Chuck Blake Wrote:
Hi. I realize that 64-bit phobos is relatively work in progress. I thought
I'd contribute. struct_stat64 is broken on Linux x86_64 which further breaks
an awful lot of file IO.
I have a small patch that fixes it by just adding a version fork for X86_64 in
the default
Walter Bright Wrote:
Jason House wrote:
I wish I had your problems. I ported a sizable set of C++ code to D2 and
discovered D2 with dmd was 50x slower than C++ with gcc! I've been to
busy/disappointed to track down the bug(s) causing such a slowdown. If
anyone
is sufficiently inspired
Simen kjaeraas Wrote:
Jason House jason.james.ho...@gmail.com wrote:
I wish I had your problems. I ported a sizable set of C++ code to D2 and
discovered D2 with dmd was 50x slower than C++ with gcc! I've been to
busy/disappointed to track down the bug(s) causing such a slowdown
Andrei Alexandrescu Wrote:
On 12/12/10 5:06 PM, Simen kjaeraas wrote:
If no-one else has stepped up, I'm willing to have a look.
That would be a great help to the community. I did look at that code and
nothing jumped at me. But then I didn't have enough time to profile it
properly.
Craig Black Wrote:
One more thing - to clarify, Craig, are you implying that it's acceptable
for performance to be within 20%? If not, there are tweaks on the
algorithmic side we can do to improve sorting.
20% slower would be acceptable if I didn't have to do my own inlining.
Closing
Jason House Wrote:
Craig Black Wrote:
One more thing - to clarify, Craig, are you implying that it's acceptable
for performance to be within 20%? If not, there are tweaks on the
algorithmic side we can do to improve sorting.
20% slower would be acceptable if I didn't have to do
Andrei Alexandrescu Wrote:
What do Walter and Andrei think?
That I'd like to know.
I think actually offering a patch is a great initiative!
Yeah, it's great initiative. Working prototypes really make it easy to fully
evaluate an option and require almost no effort to formally adopt.
Michel Fortin Wrote:
On 2010-12-08 17:26:02 -0500, Walter Bright newshou...@digitalmars.com said:
Michel Fortin wrote:
That said, what's a tail const function?
applying tail const to a function type
You mean as the return type? I'll add a unit test for that. But on the
whole, I'd
Walter Bright Wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
This seems pretty urgent. Walter?
I asked Jordi, who prepares the .deb files.
Should the binaries be installed on /usr/local/bin instead?
I'd vote for /dev/null
Make a separate package for all the extras, and
Michel Fortin Wrote:
The point is that the 'ref' in in the 'b' and 'c' variable declaration
has the effect of changing the ref from B and C from const to mutable,
even for B where the ref was explicitly specified to be const. I was
wondering if some people would find that surprising, but if
Jonathan M Davis Wrote:
On Sunday 05 December 2010 23:59:58 so wrote:
On Mon, 06 Dec 2010 02:51:32 +0200, Michel Fortin
michel.for...@michelf.com wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=5325
Great!
See the strange predicate for the const(Object) version? That's
Jason House Wrote:
Jonathan M Davis Wrote:
On Sunday 05 December 2010 23:59:58 so wrote:
On Mon, 06 Dec 2010 02:51:32 +0200, Michel Fortin
michel.for...@michelf.com wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=5325
Great!
See the strange predicate
Don Wrote:
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
T0 - As soon as there are concrete plans for a replacement. I'd also mark
sub-par modules aslooking for someone to replace this. Truth in advertising
is always appreciated.
T1 - As soon as replacement code is available or maybe a month after it's
available. Regardless, I'd update the scheduled
My last bug bug was closest to either memory corruption or misuse of druntime
API. Mix in that it only happened with concurrency, it involved a poorly
understood 3rd party API (C++ code), and awful gdb support, and you have a mix
that has soured me on D development to this day!
This was in a
I believe dmd looks for up to two errors when looking for a candidate match. I
agree that for single letter variables that doesn't make a lot of sense. Even
for two letter symbols it probably doesn't make much sense either.
spir Wrote:
PS: for got to ask: is there any kind of namespace in D
A cast to immutable is required when constructing immutable objects. The type
system can't prove that's safe. It's a design limitation to keep complexity low.
http://www.digitalmars.com/d/2.0/phobos/std_regexp.html
Looking at the Regexp docs, find isn't marked const or pure. If that's an
Steve Teale Wrote:
On Fri, 19 Nov 2010 08:25:17 -0500, Jason House wrote:
A cast to immutable is required when constructing immutable objects. The
type system can't prove that's safe. It's a design limitation to keep
complexity low.
Jason,
But design limitations like
I'm not familiar with the API, but are you able to declare your original _sta
as immutable and call it a day? Immutable data should have the same protection
as __gshared but with no implications of bypassing the type system.
If that's not helpful, can you give more details like calling
Michel Fortin Wrote:
I posted on my blog a preliminary document outlining what I intent to
implement in DMD to support the Objective-C object model.
http://michelf.com/weblog/2010/dobjc-preliminary-design/
Comments?
It looks like a few things are already implemented. I'd recommend
Tomek SowiÅski Wrote:
It may sound ridiculous but this is what came to me in a dream last night:
why exactly does
Bounded have to express an interval? Forget intervals for a minute:
struct Bounded(alias Pred, T);
where Pred is a unary callable returning bool (same as in e.g.
Don Wrote:
Don wrote:
The docs currently state that:
PROPOSAL:
Drop the first requirement. Only one requirement is necessary:
A pure function does not read or write any global mutable state.
Wow. It seems that not one person who has responded so far has
understood this
I think you need to forbid access to shared state as well. It's possible to
allow it if a strongly pure function calls a weakly pure function in an object
that it created, but that seems unnecessarily complex. Actually, that makes me
wonder: can constructors be marked pure?
Don Wrote:
Don
Walter Bright Wrote:
A pure function also cannot modify any data via its parameters. In other
words,
its parameters must be transitively const.
A weakly pure function should be able to take mutable inputs and modify them.
When called from a strongly pure function, the mutable data can only
That looks like something that should go into bugzilla.
klickverbot Wrote:
Putting the overloading issue aside for a moment, how would you
implement it inside a member function of a (which is required for
various reasons?
The following does *not* work, because A.foo also performs a vtbl
safeD doesn't mean your code is safe... only memory safe. Similarly, shared
sort of partitions data and there is no provably safe way to create or use it.
I have no idea if your example is truly legit safeD or not...
dsimcha Wrote:
I noticed that the following code compiles even in SafeD. Is
Does ddmd use/port the back end? If so, you may be violating the backend
license. If not, what are you using as the backend?
Denis Koroskin Wrote:
dolive Wrote:
thanks£¬great work !
make an all out effort !
I've implemented 127 missing methods (958 down to 831) yesterday.
druntime
vote++
It's worth an @keyword if it keeps things simple for both users and the
compiler.
Andrei Alexandrescu Wrote:
Chris Williams wrote:
I'm not sure whether the design of D 2.0 has stabilized as yet, but if not,
I would like to suggest the ability to create custom block types.
[snip]
Which platforms are supported? Linux? OSX? FreeBSD? I hope it isn't
Windows-only!
Aldo Nunez Wrote:
I'll be posting the D debugger I've been working on at dsource this week.
It'll
be a set of debugging libraries that you can build your own debugger with,
along
with a Debug Engine plug-in
What about
I don't know enough about the issue to form an opinion.
and
I don't care, I don't/rarely use delete anyway.
The latter one would have gotten my vote.
Steven Schveighoffer Wrote:
On Tue, 13 Jul 2010 11:35:55 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 07/13/2010 10:34 AM, Andrei Alexandrescu wrote:
On 07/13/2010 01:26 AM, Graham St Jack wrote:
I have jumped back onto the D2 band-wagon after a long absence,
Simen kjaeraas Wrote:
Leandro Lucarella llu...@gmail.com wrote:
it would be nice
to have some sort of way to tell the compiler to write the template
constraints for us (the obvious ones at least, there might be other
template constraints desired besides the ones the ones the compiler can
Earlier today, a test suite was added on dsource. Now may be an opportune time
to shape how this turns out.
Max Samukha Wrote:
There was a discussion about those a while ago that terminated with
Andrei's authoritative it would be a step backward.
I am not entirely convinced that there had been a step forward in the
first place. Defining static construction order to be determined by the
module
Andrei Alexandrescu Wrote:
On 05/25/2010 09:07 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
On 05/25/2010 08:31 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
On 05/25/2010 07:35 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
I've uploaded a work in progress on the
Walter Bright Wrote:
Jason House wrote:
Walter Bright Wrote:
Jason House wrote:
7. Compiler-assisted verification.
For interfaces, the compile time checking is limited to verifying that
functions with the right signature are supplied. Templates can go
considerably beyond
Andrei Alexandrescu Wrote:
On 05/26/2010 07:38 AM, Jason House wrote:
Andrei Alexandrescu Wrote:
On 05/25/2010 09:07 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
On 05/25/2010 08:31 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
On 05/25/2010 07:35 PM, Walter Bright
Andrei Alexandrescu Wrote:
We've had a tremendous infusion of talent and energy in Phobos, and
lately work has picked up in unprecedented ways, both in terms of new
features and bug fixes. I can't say how happy I am about that!
At the end of this starting week, on Friday May 28, TDPL will
Walter Bright Wrote:
Jason House wrote:
7. Compiler-assisted verification.
For interfaces, the compile time checking is limited to verifying that
functions
with the right signature are supplied. Templates can go considerably beyond
that
with the constraint checking.
constraints
Walter Bright Wrote:
Steven Schveighoffer wrote:
I'd ask the naysayers of interfaces for dcollections, and also the
supporters: what is the point of having interfaces in D? Are interfaces
pretty much obsolete, and I am just nostalgic about their utility?
Interfaces are for runtime
Walter Bright Wrote:
I tried the web interface with an iPod, it's unusable. Anyone know of an iPod
app that functions well as a decent newsgroup reader?
I use
http://www.digitalmars.com/webnews/newsgroups.php?search_txt=group=digitalmars.D
on my iPhone.
Walter Bright Wrote:
Jason House wrote:
Walter Bright Wrote:
I tried the web interface with an iPod, it's unusable. Anyone know of an
iPod
app that functions well as a decent newsgroup reader?
I use
http://www.digitalmars.com/webnews/newsgroups.php?search_txt=group
Nick B nick_nospam_.barbal...@gmail.com Wrote:
Can any one give a short update as to what has been happening/decided
on the concurrency front lately, especially in regards to D 2.0
regards
Nick B
Buy Andrei's book ;)
I have the impression that the language spec escaped more or less
pure is a keyword in D2 that means something different than how you're using
it. I also find it unusual that you use D2 range terminology but then give
examples that don't use D ranges!
I'm also fairly ignorant about what is in std.algorithm, but you should be able
to find things that look
Sean Kelly Wrote:
Don nos...@nospam.com wrote:
bearophile wrote:
dmd D 2.045 improves the built-in unit tests resuming their run when
they fail (it reports only the first failed assert for each unit
test).
There are many features that today a professional unittest system
is
Don Wrote:
Walter Bright wrote:
Don wrote:
Walter Bright wrote:
Don wrote:
There are several compiler bugs relating to array operations, and
almost all relate to this issue. I'd like to fix them, but I need to
know which way it is supposed to work.
The [] should be required. I
:03 -0400, Jason House
jason.james.ho...@gmail.com said:
Don Wrote:
x[] = sin(y[]);
I strongly favor the first syntax since it matches how I'd write it
in a for loop.
i.e. I'd replace [] with [i].
This is the best way to see array operations I've read up to now
It is my understanding that several Tango developers no longer follow
digitalmars.D. I recommend posting to the Tango forums.
I have been assuming the path of least resistance for D2 Tango was for Tango to
replace a few components with their druntime equivalent. That would allow Tango
and
Steven Schveighoffer Wrote:
Given that structs have become extremely powerful, and with the advent of
opDispatch, would it be possible to deprecate supporting COM via D
interfaces in favor of a library solution?
Don suggested defining them the same way as C++ classes.
There are some
Steven Schveighoffer Wrote:
On Tue, 13 Apr 2010 15:50:36 -0400, Christoph Mueller
ruu...@googlemail.com wrote:
I'm currently writing a library in D2 which uses intensively interfaces
and i meet a problem by overloading the opEquals Operator.
In some of my implementations i want to
Don Wrote:
Kagamin wrote:
Don Wrote:
A big start would be ditching the newsgroups for proper forum software.
I know a lot of people here prefer the newsgroups, but like it or not
this is 2010. Newsgroups are from yesteryear.
I have to say, most forums seem incredibly amateurish to
bearophile Wrote:
Steven Schveighoffer:
I feel like we will eventually need to correctly solve these types of
problems. I think it could already be done using alias this for custom
types, but the builtins would need to be treated specially.
I am ignorant about this topic, so I keep
1 - 100 of 465 matches
Mail list logo
