On Wednesday, 21 March 2018 at 23:05:22 UTC, Jonathan M Davis
wrote:
On Wednesday, March 21, 2018 22:50:32 Ontonator via
Digitalmars-d-learn wrote:
On Wednesday, 21 March 2018 at 06:39:22 UTC, ag0aep6g wrote:
> On 03/21/2018 01:47 AM, Ontonator wrote:
>> The following code does not compile:
>>>
On Wednesday, March 21, 2018 22:50:32 Ontonator via Digitalmars-d-learn
wrote:
> On Wednesday, 21 March 2018 at 06:39:22 UTC, ag0aep6g wrote:
> > On 03/21/2018 01:47 AM, Ontonator wrote:
> >> The following code does not compile:
> >>> [...]
> >>
> >> It gives the error:
> >>> [...]
> >>
> >> The
On Wednesday, 21 March 2018 at 06:39:22 UTC, ag0aep6g wrote:
On 03/21/2018 01:47 AM, Ontonator wrote:
The following code does not compile:
[...]
It gives the error:
[...]
The aliases do not have to be aliases, as long as there is
some reference to the class (e.g. method and variable
On 03/21/2018 01:47 AM, Ontonator wrote:
The following code does not compile:
void main() {}
class SuperClass {}
class TemplatedClass(T : SuperClass) {}
class A : SuperClass {
alias T = TemplatedClass!B;
}
class B : SuperClass {
alias T = TemplatedClass!C;
}
class C : SuperClass {}
On Wednesday, March 21, 2018 00:47:18 Ontonator via Digitalmars-d-learn
wrote:
> The following code does not compile:
> > void main() {}
> >
> > class SuperClass {}
> >
> > class TemplatedClass(T : SuperClass) {}
> >
> > class A : SuperClass {
> >
> > alias T = TemplatedClass!B;
> >
> > }
> >
The following code does not compile:
void main() {}
class SuperClass {}
class TemplatedClass(T : SuperClass) {}
class A : SuperClass {
alias T = TemplatedClass!B;
}
class B : SuperClass {
alias T = TemplatedClass!C;
}
class C : SuperClass {}
It gives the error:
test.d(12): Error:
On 3/6/18 5:27 PM, Timon Gehr wrote:
The reasoning "the reference is stored in the type yet not part of the
type" does not work for pure functions, as then you cannot offer an
alternative explanation in terms of an external data store.
Yeah, the more I think about it, the more I think the
On 06.03.2018 17:19, Steven Schveighoffer wrote:
unittest {
int n = 0;
struct S {
int fun() const { return n; }
}
immutable S s;
assert(s.fun == 0);
n++;
assert(s.fun == 1); // Not so immutable now, are you?
}
That's not a demonstration of breaking
On 3/6/18 10:00 AM, Simen Kjærås wrote:
On Tuesday, 6 March 2018 at 13:56:30 UTC, Steven Schveighoffer wrote:
On 3/6/18 8:42 AM, Simen Kjærås wrote:
unittest {
int i = 0;
struct S {
int n;
void fun() const {
i++;
}
}
const S s;
On 3/6/18 9:42 AM, Shachar Shemesh wrote:
I fail to see any reasoning[1] that disallows the former but allows the
later.
1 - That is obviously not true. I see the reasoning all too well. Static
vars are like globals, and you're not getting to them via the struct's
instance. I would argue
On 06/03/18 17:00, Simen Kjærås wrote:
Interestingly, replacing 'const' with 'immutable' on fun gives a
compilation error: "immutable function 'foo.__unittest_foo_1_0.S.fun'
cannot access mutable data 'n'".
This just means it is completely and totally broken. Changing the
"const" to
On Tuesday, 6 March 2018 at 13:56:30 UTC, Steven Schveighoffer
wrote:
On 3/6/18 8:42 AM, Simen Kjærås wrote:
unittest {
int i = 0;
struct S {
int n;
void fun() const {
i++;
}
}
const S s;
assert(i == 0);
s.fun();
Filed issue 18563
Shachar
On 06/03/18 16:06, Steven Schveighoffer wrote:
On 3/6/18 8:56 AM, Steven Schveighoffer wrote:
So a bug report is in order. It should be decided one way or another
-- either the context pointer is part of the struct type or it isn't.
There is a third possibility:
It's part of the type AND
On 3/6/18 8:56 AM, Steven Schveighoffer wrote:
On 3/6/18 8:42 AM, Simen Kjærås wrote:
It's a bug. As pointed out elsewhere in this thread, it compiles
correctly when there's no destructor. Essentially, this bug is caused
by the context pointer being typed as void*, and becoming (of course)
On 3/6/18 8:42 AM, Simen Kjærås wrote:
It's a bug. As pointed out elsewhere in this thread, it compiles
correctly when there's no destructor. Essentially, this bug is caused by
the context pointer being typed as void*, and becoming (of course)
const(void*) for a const(S). If it'd been
On Tuesday, 6 March 2018 at 12:00:43 UTC, Steven Schveighoffer
wrote:
On 3/6/18 6:21 AM, Simen Kjærås wrote:
On Tuesday, 6 March 2018 at 10:03:54 UTC, Shachar Shemesh
wrote:
void main() {
struct S {
uint value;
~this() {
}
}
const S a = S(12);
S b = a;
On 3/6/18 7:44 AM, Shachar Shemesh wrote:
On 06/03/18 14:00, Steven Schveighoffer wrote:
On 3/6/18 6:21 AM, Simen Kjærås wrote:
On Tuesday, 6 March 2018 at 10:03:54 UTC, Shachar Shemesh wrote:
void main() {
struct S {
uint value;
~this() {
}
}
const S a =
On 06/03/18 14:00, Steven Schveighoffer wrote:
On 3/6/18 6:21 AM, Simen Kjærås wrote:
On Tuesday, 6 March 2018 at 10:03:54 UTC, Shachar Shemesh wrote:
void main() {
struct S {
uint value;
~this() {
}
}
const S a = S(12);
S b = a;
}
test.d(10): Error:
On 3/6/18 6:21 AM, Simen Kjærås wrote:
On Tuesday, 6 March 2018 at 10:03:54 UTC, Shachar Shemesh wrote:
void main() {
struct S {
uint value;
~this() {
}
}
const S a = S(12);
S b = a;
}
test.d(10): Error: cannot implicitly convert expression a of type
On 06/03/18 12:16, Diego wrote:
You cannot assign a const element (`a`) to a non-const element (`b`) in
`S b = a` expression.
Sure you can. During assignment you are making a copy. Why do you care
whether the original is const?
Shachar
On Tuesday, 6 March 2018 at 10:03:54 UTC, Shachar Shemesh wrote:
void main() {
struct S {
uint value;
~this() {
}
}
const S a = S(12);
S b = a;
}
test.d(10): Error: cannot implicitly convert expression a of
type const(S) to S
Looks like a bug to me -
On Tuesday, 6 March 2018 at 10:03:54 UTC, Shachar Shemesh wrote:
void main() {
struct S {
uint value;
~this() {
}
}
const S a = S(12);
S b = a;
}
You cannot assign a const element (`a`) to a non-const element
(`b`) in `S b = a` expression. To make de
void main() {
struct S {
uint value;
~this() {
}
}
const S a = S(12);
S b = a;
}
test.d(10): Error: cannot implicitly convert expression a of type
const(S) to S
Doing *any* of the following makes the code compile:
* Making the struct "static"
* Making
import std.stdio;
void Foo(T:T*)(T arg) if(!is(T==int)) {
writeln(arg of Foo:, arg, typeid(T));
}
void Foo(T:T*)(T arg) if(is(T==int)) {
writeln(int Foo!);
}
void main() {
Foo!(long*)(54);
}
Morlan:
...
This compiles, 54 is an int:
import std.stdio;
void Foo(T: T*)(T arg) if(!is(T == int)) {
writeln(Arg of Foo: , arg, , typeid(T));
}
void Foo(T: T*)(T arg) if(is(T == int)) {
writeln(int Foo!);
}
void main() {
Foo!(long*)(54L);
}
Generally for questions like this,
I did not ask what to do to compile it. I knew that 54L would do. The problem is
that in the example I explicitely specify the template parameter as long* so
there
is no reason for the compiler to try and guess T from the type of the function
argument. There is something wrong here.
Am 24.03.2011 11:49, schrieb Morlan:
I did not ask what to do to compile it. I knew that 54L would do. The problem is
that in the example I explicitely specify the template parameter as long* so
there
is no reason for the compiler to try and guess T from the type of the function
argument. There
The program below compiles. Clearly the if constraints in my original example
are causing trouble. It seems like a bug to me.
import std.stdio;
void Foo(T:T*)(T arg) {
writeln(arg of Foo:, arg, typeid(T));
}
void main() {
Foo!(long*)(54);
}
Morlan:
I did not ask what to do to compile it. I knew that 54L would do. The problem
is
that in the example I explicitely specify the template parameter as long* so
there
is no reason for the compiler to try and guess T from the type of the function
argument. There is something wrong
30 matches
Mail list logo
