__restrict

[Manu]

I agree, that is certainly more important :)

I'm mainly just curious to know about how the main contributors feel about
these things, and whether these things will be implemented/planned, or if
they violate some fundamental language principles...
Basically, I really want to start some major work in D, but before investing
into the language, I want to know that important features are recognised and
have a long term plan...

I'm curious to know what you mean by "maybe also because in D where possible
we prefer things that the compiler is able to verify/enforce". I'm not sure
how that really applies to __restrict. It's effectively an optimisation hint
to the compiler, giving it explicit instructions... what would there be to
verify or enforce in this case? Is it that it would be preferred if
__restrict-ability could be implied by carefully crafted language rules? I
just don't think that's possible.. But it's still an important keyword.

How difficult is it to contribute to D in these areas? Is that something
that is encouraged, or is D still too embryonic to have random people coming
along and adding things here and there?

On 19 October 2011 12:36, bearophile <bearophileHUGS at lycos.com> wrote:

> Manu:
>
> > I sent an email about this once before... but there was no real
> > response/discussion on the topic.
>
> It was discussed a bit in past, and restrict was not appreciated a lot,
> maybe also because in D where possible we prefer things that the compiler is
> able to verify/enforce.
> And I think D/DMD is not yet in a development stage where it cares for max
> performance details. I think there are plenty of more important things to
> work on before that. The recently almost-fixed "inout" was more urgent than
> "__restrict".
>
> Bye,
> bearophile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111019/b8e2c7b9/attachment.html>