On Tuesday, 12 January 2021 at 21:38:59 UTC, sighoya wrote:
What about this?
No magic, but I don't know the performance impact.
```
import std.meta;
import std.conv;
template same(Types...)
{
static if (Types.length >= 2)
{
static if (is(Types[0] == Types[$ - 1]))
{
What about this?
No magic, but I don't know the performance impact.
```
import std.meta;
import std.conv;
template same(Types...)
{
static if (Types.length >= 2)
{
static if (is(Types[0] == Types[$ - 1]))
{
const same = same!(Types[1 .. $]);
}
Ok, so I now have this, but I think maybe the switch could be
turned into a static array by an reinterpret cast of
"[0]"? I would assume the layout would typically be
"expand_field_0, expand_field_1 etc...
template Tuple(Types...){
template same(){
static foreach (i, dummy;
On Monday, 11 January 2021 at 20:52:25 UTC, Paul Backus wrote:
All of what you're saying applies equally well to any struct
type as it does to tuples.
Sure.
It sounds like what you really want is for D *in general* to
have head-const, for all types. So there's no reason to force
it on
On Monday, 11 January 2021 at 20:36:30 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 19:25:06 UTC, Paul Backus wrote:
I agree that immutability has benefits, but I don't see why
tuples should be singled out for special treatment in this
regard.
Oh, and another reason is that
On Monday, 11 January 2021 at 19:25:06 UTC, Paul Backus wrote:
I agree that immutability has benefits, but I don't see why
tuples should be singled out for special treatment in this
regard.
Oh, and another reason is that scalars can usually be passed by
value with impunity, but you might
On Monday, 11 January 2021 at 19:25:06 UTC, Paul Backus wrote:
On Monday, 11 January 2021 at 18:02:19 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 17:48:13 UTC, Paul Backus wrote:
Why? I'd say that an `immutable(Tuple)` should be immutable,
and a `Tuple` should be mutable, as
On Monday, 11 January 2021 at 18:02:19 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 17:48:13 UTC, Paul Backus wrote:
Why? I'd say that an `immutable(Tuple)` should be immutable,
and a `Tuple` should be mutable, as is the case with literally
every other type in D.
Tuples are
On Monday, 11 January 2021 at 17:48:13 UTC, Paul Backus wrote:
Why? I'd say that an `immutable(Tuple)` should be immutable,
and a `Tuple` should be mutable, as is the case with literally
every other type in D.
Tuples are usually immutable, it brings more correctness.
On Monday, 11 January 2021 at 14:51:29 UTC, Ola Fosheim Grøstad
wrote:
Basically, the tuple itself should be immutable, but not the
objects being referenced. I guess I could run over the types
and add const if they are not references?
Why? I'd say that an `immutable(Tuple)` should be
On Monday, 11 January 2021 at 14:53:08 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 14:51:29 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:
alias expand this;
Hm... this does not allow me protect the fields from being
On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:
alias expand this;
Hm... this does not allow me protect the fields from being
changed. I also cannot use const since it is transitive and would
make it impossible to return two references to mutable objects?
Basically, the
On Monday, 11 January 2021 at 14:51:29 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:
alias expand this;
Hm... this does not allow me protect the fields from being
changed. I also cannot use const since it is transitive and
would make it
On Monday, 11 January 2021 at 14:03:39 UTC, Paul Backus wrote:
On Monday, 11 January 2021 at 09:42:39 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 05:59:03 UTC, Paul Backus wrote:
You can just fall back to `alias expand this` like Phobos's
Tuple does in this case. No compiler
On Monday, 11 January 2021 at 09:42:39 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 January 2021 at 05:59:03 UTC, Paul Backus wrote:
You can just fall back to `alias expand this` like Phobos's
Tuple does in this case. No compiler modification needed.
I though maybe it would be nice in
On Monday, 11 January 2021 at 09:42:39 UTC, Ola Fosheim Grøstad
wrote:
I though maybe it would be nice in general to be able to create
static indexed type by having a special field name pattern, but
I will have a another look at staticMap (I don't really want
the full staticMap into object.d
On Monday, 11 January 2021 at 05:59:03 UTC, Paul Backus wrote:
static if (allSameType) {
auto opIndex(size_t i) {
switch (i) {
static foreach (j; 0 .. Types.length) {
case j: return this.expand[j];
}
default: assert(0); // or throw
On Monday, 11 January 2021 at 05:44:19 UTC, Ola Fosheim Grostad
wrote:
On Monday, 11 January 2021 at 01:49:26 UTC, Paul Backus wrote:
Why are these particular implementation details important to
you?
It is for object.d.
I want to allow fast runtime indexing if all elements are of
the same
On Monday, 11 January 2021 at 01:49:26 UTC, Paul Backus wrote:
Why are these particular implementation details important to
you?
It is for object.d.
I want to allow fast runtime indexing if all elements are of the
same type.
If the types are different I want static indexing, so the plan is
On Sunday, 10 January 2021 at 16:52:30 UTC, Ola Fosheim Grøstad
wrote:
I want to create my own Tuple type, and I don't like the messy
implementation of the one in D's standard lib, or the one in
Clang++'s standard lib. The concept is very simple so it is
disheartening if it cannot be done in a
20 matches
Mail list logo
