Skip to content
This repository was archived by the owner on Oct 12, 2022. It is now read-only.

[WIP] core.array.staticArray static array litteral: staticArray(1, 2, 3) #2093

Closed
wants to merge 13 commits into from

Conversation

timotheecour
Copy link
Contributor

@timotheecour timotheecour commented Feb 14, 2018

usage

auto a = staticArray(1, 2, 3);
float[2] = staticArray!float(1, 2);

motivation

places like here: dlang/dub#1377 (comment)

notes

  • NOTE: in core.runtime so it can be used in more settings including dmd compiler which can't use phobos

  • NOTE: other (stalled) PR's have proposed something like staticArray(T)(T[] a) ; I suggest this could be done instead (in another PR) via (something like) toStaticArray(T)(T[]a) to avoid name ambiguity

links

https://issues.dlang.org/show_bug.cgi?id=8008 Issue 8008 - Syntax for fixed size array literals like [1,2,3]s (edit)
https://issues.dlang.org/show_bug.cgi?id=481 Issue 481 - Fixed-length arrays with automatically computed length (edit)
dlang/phobos#4936 Fix Issue 16745 - Add template helper for creating static arrays with the size inferred #4936
dlang/phobos#4090 Better static array support in std.array #4090

not related

https://issues.dlang.org/show_bug.cgi?id=9165 Issue 9165 - Auto conversion from dynamic array to fixed size array at return (edit)

TODO

  • update the dreadful mak/*
  • decide whether to put in std.array or core.array
  • decide whether both staticArray and asStatic are needed or whether asStatic is sufficient
  • probably need to add asStaticCast as well for symmetry (is there a better way to avoid the code dup?)
  • should i make rename staticArrayCast as staticArray so that there's no user-looking difference bw case where an explicit cast is needed vs not.

@dlang-bot dlang-bot added the WIP Work In Progress - not ready for review or pulling label Feb 14, 2018
@dlang-bot
Copy link
Contributor

Thanks for your pull request and interest in making D better, @timotheecour! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.


If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

src/core/array.d Outdated
return [a];
}

unittest
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make the unittest public, s.t. it's visible on the docs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also add @nogc @safe nothrow and pure. A static array should be usable in the full set.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also add @nogc @safe nothrow and pure. A static array should be usable in the full set.

done

Make the unittest public, s.t. it's visible on the docs.

not done yet

Copy link
Contributor Author

@timotheecour timotheecour Feb 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make the unittest public, s.t. it's visible on the docs.

done

src/core/array.d Outdated
/++
Returns a static array constructed from `a`. The type of elements can be
specified implicitly (`int[2] a = staticArray(1,2)`) or explicitly
(`float[2] a = staticArray!float(1,2)`).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Params + Returns

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this is too much boilerplate and doesn't add anything in this case; looking at https://dlang.org/phobos/std_array.html#array , functions where it's obvious from rest of ddoc don't do it either.

auto a = staticArray(1, 2.0);
assert(is(typeof(a) == double[2]));
assert(a == [1, 2.0]);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simply create new unittest blocks instead of scoping. It doesn't hurt and allows the user of the documentation to hit "run" and "edit" for an individual block. Plus you can give a short summary title in /// Amazing example

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pushing back on this request as well, but happy to revisit if you have good arguments

  • creates less visual clutter to group (and takes less vertical space both in rendered doc and in source code); the inline comments will still be visible in rendered docs
  • (maybe this one isn't an important point) potentially less executable / compile time / runtime bloat

src/core/array.d Outdated
}

package:
// copied from std.traits ; TODO: move to core.internal.adapted?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, imho std.traits and std.meta should have been part of druntime, but yeah for nor core.internal.traits is the place to dump traits from Phobos.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@wilzbach
Copy link
Member

Missing comments from Andrei:

  • Add an overload that takes a range and is meant to be evaluated during compilation
  • Add documentation explaining the tradeoffs of the rvalue return
  • add constraint if (is(T : TargetElemT))

@jmdavis
Copy link
Member

jmdavis commented Feb 14, 2018

Well, this implementation is going to have problems with VRP, but until https://issues.dlang.org/show_bug.cgi?id=16779 is fixed, we don't have a way around that.

Regardless though, this isn't the sort of thing that normally goes in druntime. Typically, only the stuff that needs to go in druntime goes in druntime, and this isn't needed in druntime. It belongs in Phobos.

@timotheecour
Copy link
Contributor Author

done:Add an overload that takes a range and is meant to be evaluated during compilation
done:Add documentation explaining the tradeoffs of the rvalue return
done:add constraint if (is(T : TargetElemT))

Regardless though, this isn't the sort of thing that normally goes in druntime. Typically, only the stuff that needs to go in druntime goes in druntime, and this isn't needed in druntime. It belongs in Phobos.

I was hesitationg as well. Would be useful to have access to it in compiler, which uses druntime and not phobos. Let's delay that decision until rest of PR is good so i don't keep moving files around

@skl131313
Copy link
Contributor

I was hesitationg as well. Would be useful to have access to it in compiler, which uses druntime and not phobos. Let's delay that decision until rest of PR is good so i don't keep moving files around

All of phobos would be useful to have access in the compiler. Should everything be backported to druntime then? If the answer is no, then this shouldn't be included either. If you want access to phobos-like features then an effort should be be made into getting phobos running in the compiler. Don't know DMD's structure that well but if it isn't possible then a separate library that only DMD uses should be created instead.

@wilzbach
Copy link
Member

If you want access to phobos-like features then an effort should be be made into getting phobos running in the compiler.

There's no effort required for this, it's a deliberate decision from Walter to explicitly avoid using Phobos. Phobos could already be used at dmd - in fact the HOST_DMD even links with it, but the linker strips it out as it's not used.

@skl131313
Copy link
Contributor

Oh I thought it wasn't used cause it wasn't possible. Then this definitely shouldn't go into druntime. If features like these are desired in DMD then someone needs to convince for phobos to be used in DMD.

@timotheecour
Copy link
Contributor Author

timotheecour commented Feb 15, 2018

ok @skl131313 u convinced me, will reopen a PR after all these issues are cleared

cc @WalterBright

someone needs to convince for phobos to be used in DMD

yes! I don't understand the decision for dmd not being allowed to use phobos btw, that just creates all this ugly guesswork and copies in core.internal, and makes dmd sub-optimal and verbose in many places. Arguments against need to be clearly written down so they can be fought

src/core/array.d Outdated
specified implicitly (`int[2] a = staticArray(1,2);`) or explicitly
(`float[2] a = staticArray!float(1,2)`).

The result is an rvalue, therefore uses like staticArray(1, 2, 3).find(x) may be inefficient.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe providing some links to what an rvalue is or explaining the inefficiency a bit better. Just from the stand point of someone that isn't familiar with what rvalues are and why this might be inefficient. Using find(staticArray(...), x) might better illustrate that point as well.

Copy link
Contributor Author

@timotheecour timotheecour Feb 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe providing some links to what an rvalue is

i think that's out of scope; other functions mentioning rvalue don't explain either

explaining the inefficiency a bit better.

done

find(staticArray(...), x)

changed it to fun(staticArray(...))

@timotheecour
Copy link
Contributor Author

@jmdavis

Well, this implementation is going to have problems with VRP, but until https://issues.dlang.org/show_bug.cgi?id=16779 is fixed, we don't have a way around that.

added staticArrayCast which allows casting

@timotheecour
Copy link
Contributor Author

after feedback from reviewers, moved to a new PR under phobos: dlang/phobos#6178

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
WIP Work In Progress - not ready for review or pulling
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants