Re: How to partially forward properties of struct array member to struct (disable length property) ?
On Sunday, 6 September 2015 at 10:12:58 UTC, ParticlePeter wrote:
In the end all that I want is "just" to disable access to
array.length through vector and alias this array.
struct Vec(T, size_t n = 3)
{
T[n] data;
alias data this;
@disable @property size_t length() const;
}
void main()
{
Vec!int v;
v[0] = 1; // ok
assert(v[0] == 1); // ok
int n = v.length; // error
}
- Kenji
Re: Cannot use the same template arguments on function as the ones on struct
On Wednesday, 11 February 2015 at 22:24:53 UTC, anonymous wrote: On Wednesday, 11 February 2015 at 22:14:44 UTC, MrSmith wrote: http://dpaste.dzfl.pl/5f1d5d5d9e19 Instead I need to use template constraint which is less compact. http://dpaste.dzfl.pl/571ae84d783e Why such behavior happens? Seems to work when you add an empty template argument list to `accepter()`, making it `accepter!()()`: http://dpaste.dzfl.pl/2ec186453907 So, compiler bug, I guess? The error message says it tried !()(), but explicit !()() actually works. And the empty template argument list should be optional anyway. It would be a compiler bug. As far as I know, accepter() and accepter!()() has no difference in IFTI. I filed the issue in bugzilla. https://issues.dlang.org/show_bug.cgi?id=14174 Kenji Hara
Re: class is forward referenced when looking for 'v'
On Friday, 30 January 2015 at 00:09:17 UTC, Amber Thralll wrote:
And the errors dmd returns:
test.d(16): Error: class test.A!int.A is forward referenced
when looking for 'v'
test.d(16): Error: class test.A!int.A is forward referenced
when looking for 'opDot'
test.d(16): Error: class test.A!int.A is forward referenced
when looking for 'opDispatch'
test.d(29): Error: no property 'v' for type 'test.A!int.A'
test.d(10): Error: template instance test.B!int error
instantiating
test.d(16):instantiated from here: Base!int
test.d(35):instantiated from here: A!int
Is this a bug in D? Or am I doing something wrong?
In D, forward reference resolution should have consistent result
for template classes and non-template ones. If the code is
rewritten to non-template version:
import std.stdio;
class Base
{
public void Foo(A a)
{
writeln(Base.Foo(A a));
}
public void Foo(B a)
{
writeln(Base.Foo(B a));
}
};
class A : Base
{
public int v;
this(int v)
{
this.v = v;
}
}
class B : Base
{
public override void Foo(A a)
{
writeln(A: , a.v);
}
}
int main()
{
A a = new A(1);
B b = new B();
a.Foo(b);
b.Foo(a);
return 0;
}
Compiler properly resolves forward references. Therefore, it's
definitely a compiler bug, and the template version should be
accepted.
I filed the issue in bugzilla:
https://issues.dlang.org/show_bug.cgi?id=14083
And will open a new pull request to fix compiler.
Kenji Hara
Re: Segfault upon modifying immutable AA in static this
On Saturday, 24 January 2015 at 13:29:36 UTC, Nordlöw wrote: The issue originates from module level intialization of static immutable AAs at https://github.com/nordlow/justd/blob/master/conv_ex.d Do I have to change the initialization of the AAs to be explicitly inline at definition of the AAs or can I preserve my convenient foreach over the AAs in the `static this` to automatically get the integer value to be stored? Note that this does not segdefault on latest stable DMD 2.066. It's a regression in git-head. https://issues.dlang.org/show_bug.cgi?id=14038 Kenji Hara
Re: Initialization of structure field w/o default ctor
On Thursday, 22 January 2015 at 12:45:53 UTC, drug wrote:
On 22.01.2015 15:30, bearophile wrote:
drug:
Also can I avoid dummy non-default ctor for Bar?
One solution:
struct Foo {
int foo;
@disable this();
this(int foo_) pure nothrow @safe @nogc {
this.foo = foo_;
}
}
struct Bar {
enum arraySize = 3;
Foo[arraySize] foo = Foo(1);
}
void main() @safe {
import std.stdio;
Bar bar;
bar.writeln;
}
Bye,
bearophile
Yes, that's what the doctor prescribed. Thank you!
Or you can use block assignment in the constructor.
struct Bar
{
enum ArraySize = 3;
Foo[ArraySize] foo;
this(string dummy) // == here because compiler demands to
initialize field foo
{
import std.algorithm: fill;
//fill(foo[], Foo(0));
foo[] = Foo(0); // == OK
}
}
Compiler can recognize the block assignment as a construction for
the field Bar.foo.
Kenji Hara
Re: Redirect to different overloads at compile time?
On Monday, 30 June 2014 at 02:24:10 UTC, David Bregman wrote:
Suppose I have a C library which implements a function for
several types. C doesn't have overloading, so their names will
be distinct.
extern(C):
double foo_double(double);
float foo_float(float);
Now I want to build a D wrapper, and merge them into a single
function with overloading:
T foo(T)
I could write out the two overloads manually:
double foo(double d) { return foo_double(d); }
float foo(float f) { return foo_float(f); }
but this isn't compile time, it will generate a stub function
for each overload, meaning the wrapper will have performance
overhead unless inlining can be guaranteed somehow.
Is it possible to do something like
alias foo = foo_double;
alias foo = foo_float;
In D, you can merge arbitrary overloads by using alias
declaration.
import std.stdio;
extern(C)
{
double foo_double(double a) { writeln(typeof(a).stringof);
return a; }
float foo_float (float a) { writeln(typeof(a).stringof);
return a; }
}
alias foo = foo_double;
alias foo = foo_float;
void main()
{
double d;
float f;
foo(d); // prints double
foo(f); // prints float
}
Kenji Hara
Re: Don't Understand why Phobos Auto-Tester fails for PR #3606
On Saturday, 7 June 2014 at 08:56:38 UTC, Nordlöw wrote: My recent https://github.com/D-Programming-Language/dmd/pull/3606 fails in all the Auto-Testers but I don't understand why. Running make unittest locally in phobos using my locally built branch of dmd passes all tests. Please help! I commented in github. Kenji Hara
