Fix Issue 11336 - ElementType does not support types with disabled postb...

[monarchdodra]

...lits

The root issue was an old hack which tested via a function a return by value. No postblit => no return by value.

I was able to work around the entire hack by simply using @denis-sh 's lvalueOf. A really neat thing about lvalueOf is that it has the whole inout hack "integrated" into it, so the hack can be entirely removed from the calling code. No hack => no function => no problem :)

The makes the final code trivial and straight forward. I'll really loving this lvalueOf trait.

@denis-sh : You introduced the hack (AFAIK), and implemented lvalueOf: Do you see anything here I might have missed?

If this is correct, I think it's time to do a pass on all of range/traits and deploy lvalueOf...

http://d.puremagic.com/issues/show_bug.cgi?id=11336

[denis-sh]

You introduced the hack (AFAIK)

Nop. It was Kenji in 900fa89. I just removed dummy arguments in db1d909.

Do you see anything here I might have missed?

About lvalueOf!R[0]:
A long time ago I proposed ArrayElementType trait but it was rejected as "useless" and people still write typeof(a[0]) (IIRC I was also told to use ElementEncodingType when array element type is needed which is purely insane IMO as it misdocument the code). I'd say it is bad style to access past the end of an array (as we may have zero-length static array). So we probably should use typeof(*a.ptr) or introduce private _ArrayElementType as code self-documentation (i.e. readability) is important.

Otherwise the pull LGTM.

[monarchdodra]

as we may have zero-length static array

Hum... I had forgotten about static arrays, let alone empty arrays. ElementType worked correctly for empty arrays, but ElementEncodingType. I fixed that too, and added the unittests.

[ghost]

Added a link to bugzilla in the pull request description.

[ghost]

LGTM. The failures, as always, are completely unrelated (I really hate that we still don't have a reliable test-system due to all of these random failures..)

[braddr]

Yup, unreliable tests suck. I've got a change that's been running on a few test nodes to help address the error fetching from github (through a little retrying). The majority of the failures are not in the system, but rather the code being tested. Yeah, I'm nit picking, but it helps to place blame carefully and correctly.

[ghost]

Sorry, I'm mostly referring to the synchronization and random test42.d bugs.

[dnadlinger]

@denis-sh: Dereferencing a.ptr for a zero-length array is just the same out-of-bounds access that a[0] is.

[denis-sh]

Dereferencing a.ptr for a zero-length array is just the same out-of-bounds access that a[0] is.

Indeed. And it also fails for void[].

[monarchdodra]

Well... The difference is the compile tim;pe compatibility:
is(typeof(a[0])) is false, because the code will entirelly fail to
compile (static out of bounds), on the other hand, is(typeof(*a.ptr)) is
valid: While it's stile runtime out of bounds, the compile time test is
valid.

Indeed. And it also fails for void[].

I think it works, since the anser is void regardless :)

On Sun, Oct 27, 2013 at 6:19 PM, Denis Shelomovskij <
notifications@github.com> wrote:

Dereferencing a.ptr for a zero-length array is just the same out-of-bounds
access that a[0] is.

Indeed. And it also fails for void[].

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1658#issuecomment-27173537
.

[denis-sh]

is(typeof(a[0])) is false, because the code will entirelly fail to
compile (static out of bounds)

No, this code works now ((int[0]).init[0] is int). I just suppose it's a bad style and it can eventually stop working.

I think it works, since the anser is void regardless :)

typeof(*(void*).init) fails now with "Error: expression *null is void and has no value".

[monarchdodra]

No, this code works now ((int[0]).init[0] is int). I just suppose it's a bad style and it can eventually stop working.

Right, but *a.ptr, works and should continue to do so, so it shouldn't be a problem.

typeof((void).init) fails now with "Error: expression *null is void and has no value".

Right, but if that fails, we have else ElementType = void;, so it works regardless.

I don't see any actual case where this code will fail...