Is it bad for object.di to depend on core.exception?

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Mar 7 19:57:30 PST 2012


On Thu, Mar 08, 2012 at 12:37:20PM +1100, Daniel Murphy wrote:
> "H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote in message 
> news:mailman.176.1331147910.4860.digitalmars-d at puremagic.com...
> > On Sun, Mar 04, 2012 at 07:31:49AM +0100, Martin Nowak wrote:
> >> Wasn't the latest proposal that we add a working AA implementation
> >> to the runtime and switch the compiler after that has settled?
> >
> > Is somebody working on that? If not, I may take a crack at doing it.
[...]
> I was the one that recently tried to get AAs rolled back to the D1
> implemenation (unsuccessfully) but I'm not working on a
> reimplementation.  The closed pull requests are sitting on github if
> you'd like to take a look at them.
> 
> For it to be 'fixed', AAs need to be able to do all the things they
> can do now, including producing error messages with V[K] instead of
> AssociativeArray!(K, V), magic initialization and the same reference
> semantics.  They also need to _work_ in ctfe, either because the
> implementation is available and ctfeable, or because the calls get
> translated late enough that the interpreter can pick out the
> IndexExps/DotIdExps and treat them specially.
> 
> At the moment I'm leaning towards doing the translations in the glue
> layer, and using ufcs for everything else, but whatever works.
> There's a thread on the internals mailing list that lists some of the
> issues with the current implementation. 
[...]

Hmm. If this is going to involve major changes in *both* druntime and
dmd, I may have bitten off a bit more than I can chew. :-/ I was going
on the original statement that we build a workable AA implementation in
object_.d first, then port the compiler over. Trying to do everything at
once seems like too big a project to pull off successfully in one shot.


T

-- 
Without geometry, life would be pointless. -- VS


More information about the Digitalmars-d mailing list