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 <bearophileh...@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 >