fix for calling .array() on ranges in CTFE

[dymk]

Previously .array() could not be called on ranges in CTFE mode as it relied on calling malloc(), so code such as this would not work:

void main() {
  const a = [1, 2, 3];
  const b = a.map!("a + 1").array();
  pragma(msg, b);
}

This provides a fix so memory will be allocated with new() instead of malloc() if the compiler is in CTFE mode.

[alexrp]

new E[](sizes[0]).ptr ?

[dymk]

You learn something new everyday; thank you

[alexrp]

You should run git rebase -i HEAD~2 and mark the commit you just made as squash, then git push origin ctfe-array -f. This squashes your two last commits together so we don't have "fix last commit"-type commits in the history.

[dymk]

Ah alright, learned two things today then!

[JakobOvrum]

LGTM. The reason array uses GC.malloc directly is so it can elect not to default-initialize the new array, which doesn't seem like a valid endeavour in CTFE.

[monarchdodra]

Well, now I feel like an idiot for fixing the same issue (#1213) along with inserting safety.
For referencing the discussion about the rationale and the semantics related to the fix (http://forum.dlang.org/thread/uhvwbttbxxqzgculaacb@forum.dlang.org?page=3#post-ki84nc:2429ns:241:40digitalmars.com).
For writing unittests to actually validate the fix.
For filing a bug report in bugzilla for a related issue http://d.puremagic.com/issues/show_bug.cgi?id=9803
For fixing that bug too.

Then, having no-one review it for two months.

Well, I guess I should be happy to see something getting fixed in phobos :/

I apologize in advance for that rant (which is in no way targeted to OP of course. Thankyou @dymk for this fix).

[dnadlinger]

@monarchdodra: I was actually ready to merge your fix, but it slipped off my radar after my initial comment. In such cases, please feel free to ping me, I probably was just too busy that week to follow up on it immediately, and haven't had the time to make a complete pass through the pull request list since. If you want to rebase your pull request, I'd be glad to merge it in.

[andralex]

Many apologies @monarchdodra. I wonder what kind of process we could put in place to avoid this kind of duplicated work.

[dnadlinger]

@andralex: Merging pull requests faster. ;)

[JakobOvrum]

@monarchdodra, well, this pull request also happens to be smaller (too small clearly, I missed that it didn't add any unittests), focused and thus easy to review.

[monarchdodra]

There is no problem. I of course understand that we are all volunteers, and things sometimes get reviewed before others. In particular, 1 liner fixes will have much better chances of immediate review and merge, as opposed to a pull that fixes 2 or 3 related bugs.

There was a little bit of frustration I need to type out, but it wasn't directed at anyone. :)

[andralex]

Appreciate the understanding. I think one good next step to take is accept a few more committers. We've had a surge of new good contributors and we can recruit from them.

[denis-sh]

Also this one-line "fix" creates a nasty regression Issue 10220 - array doesn't work with disabled default construction

[dymk]

@denis-sh, I'm not sure I'd call this a regression. If it was a regression, issue 10220 would have worked in CTFE mode. However it would not have in the first place, seeing as calling malloc() doesn't (and can not) work in CTFE mode.

[denis-sh]

@dymk, when my codebase fails to compile because of dmd/phobos changes, it is what called a regression.

[monarchdodra]

It is a regression. An interesting one too: If the code fails to compile because of the __ctfe branch, then it won't compile in runtime either. This is because the "if (__ctfe)" is not static check, so the code must be valid at all times. Even if it didn't work in ctfe before.

I've found a fix. I'll integrate it into my own branch.

Gotta rebase first.

[CyberShadow]

FYI, this pull request introduced a regression by apparently uncovering a compiler bug: https://d.puremagic.com/issues/show_bug.cgi?id=12044