or not. A notable example is
forgetting to supply an arrange length when declaring a stack
array, or it'll try to create a runtime-allocated array.
I'll open a report for this shortly if it is a bug if there isn't
one already. For now, that template is an adequate workaround.
On Monday, 6 July 2020 at 20:06:51 UTC, Kayomn wrote:
Something discovered in the D Language Code Club Discord server
with the help of Wild is that the following code:
struct Test { ~this() {} }
void tester(Test test, Test[] tests...) { }
extern(C) void main() {
tester(Test(), Test());
}
Something discovered in the D Language Code Club Discord server
with the help of Wild is that the following code:
struct Test { ~this() {} }
void tester(Test test, Test[] tests...) { }
extern(C) void main() {
tester(Test(), Test());
}
Raises the "TypeInfo cannot be used with ~betterC"
.
Why is it necessary to promote a ushort or ubyte to int for the
purpose of shifting or the one's complement ?
At least the code at the bottom of the post seems to produce
correct results.
One problem I see with the bug fix is that, AFAIK, the int type
in C is not a fixed bit type like
On Monday, 11 May 2020 at 13:06:59 UTC, Steven Schveighoffer
wrote:
Clearly something isn't connecting properly, it's almost like
it's resolving to the function itself instead of calling it.
Since the imported front is also a local symbol the compiler
probably thinks it is overloaded and not
On Monday, 11 May 2020 at 13:12:37 UTC, Simen Kjærås wrote:
Filed here: https://issues.dlang.org/show_bug.cgi?id=20821
Thanks.
On Monday, 11 May 2020 at 12:44:45 UTC, Jack Applegame wrote:
On Monday, 11 May 2020 at 12:30:22 UTC, Adam D. Ruppe wrote:
UFCS is only defined to work with global scope functions. A
restricted import (module : symbol, symbols) puts things in
local scope so ufcs doesn't apply.
But in this
be displayed for lines 4 and 5, not 11.
Line 11 contains a call to a member function, not UFCS.
In addition, if you add the parentheses, then it works:
assert(rng.front() == '1');
Yeah, this is definitely a bug. If I change the return type of front to
dchar from auto, it still thinks it's
On Monday, 11 May 2020 at 12:30:22 UTC, Adam D. Ruppe wrote:
UFCS is only defined to work with global scope functions. A
restricted import (module : symbol, symbols) puts things in
local scope so ufcs doesn't apply.
But in this case the error should be displayed for lines 4 and 5,
not 11.
On Monday, 11 May 2020 at 12:20:06 UTC, Jack Applegame wrote:
If you move the import to the global scope
UFCS is only defined to work with global scope functions. A
restricted import (module : symbol, symbols) puts things in local
scope so ufcs doesn't apply.
(interestingly an unrestricted
And the first example still doesn't compile:
```
struct Range(R) {
import std.array : empty, front, popFront;
R range;
bool empty() const { return range.empty; }
auto front() const { return range.front; }
void popFront() { range.popFront(); }
}
void main() {
auto rng
On Monday, 11 May 2020 at 12:20:06 UTC, Jack Applegame wrote:
assert(rng.front == 1);
Damn! I made a typo. It must be:
assert(rng.front == '1')
So the second example works fine.
Why doesn't it compile?
```
struct Range(R) {
import std.array : empty, front, popFront;
R range;
bool empty() const { return range.empty; }
auto front() const { return range.front; }
void popFront() { range.popFront(); }
}
void main() {
auto rng = Range!string("1234");
is saved locally as
a ref int and then the destructor of S is called (set the local
cache to 0). Now the ref value is dereferenced and returned.
Now I am unsure if this is a bug or an undefined behavior that
I don't know.
If this is a bug, then I don't know how to call it for the bug
tracker.
I
On Friday, 8 May 2020 at 14:32:33 UTC, kinke wrote:
On Friday, 8 May 2020 at 14:16:10 UTC, foerdi wrote:
Now I am unsure if this is a bug or an undefined behavior that
I don't know.
This is a regression, and a potentially pretty bad one, so thx
for tracking it down!
If this is a bug
On Friday, 8 May 2020 at 14:16:10 UTC, foerdi wrote:
Now I am unsure if this is a bug or an undefined behavior that
I don't know.
This is a regression, and a potentially pretty bad one, so thx
for tracking it down!
If this is a bug, then I don't know how to call it for the bug
tracker
is called (set the local
cache to 0). Now the ref value is dereferenced and returned.
Now I am unsure if this is a bug or an undefined behavior that I
don't know.
If this is a bug, then I don't know how to call it for the bug
tracker.
I hope you can help me with this problem.
PS
On Tuesday, 5 May 2020 at 05:37:08 UTC, Simen Kjærås wrote:
On Tuesday, 5 May 2020 at 04:02:06 UTC, RazvanN wrote:
[...]
Surely the above code, which silently discards the exception,
does not print "hello"?
Regardless, I ran your code with writeln inside the catch(),
and without the
}
try
{
new C(K(), foo(true));
}
catch(Exception)
{
}
}
Result:
object.Exception@test.d(18): hello
If the destructor of K is not marked nothrow the code does not
throw an exception. Is this a bug or am I missing something?
Surely the above code, which silentl
(Exception)
{
}
}
Result:
object.Exception@test.d(18): hello
If the destructor of K is not marked nothrow the code does not
throw an exception. Is this a bug or am I missing something?
only be fixed by accident.
I thought it might be worth filing a bug, but wanted to confirm
if others thought this was actually a bug. I had encountered
an identical issue with vibe-d years ago.
Thanks for the feedback.
After some digging it appears there is already a fix for this
(though
t;income"].type beforehand and use .floating or .integer as
befits, or simply use an alternative JSON library (asdf?).
File an issue if you have the time, maybe it will get
attention. Unreported bugs can only be fixed by accident.
I thought it might be worth filing a bug, but wanted t
On Wednesday, 22 April 2020 at 17:48:18 UTC, Craig Dillabaugh
wrote:
The crash is caused because the 'income' field with value 0.0 is
output as 0 (rather than 0.0) and when it is read this is
interpreted
as an integer.
Shouldn't this work?
Yes, it's just buggy.
Giving it a value of an even
So perhaps I am the only person in the world using std.json, but
I was wondering
if the following code should work.
=
import std.json;
import std.conv;
import std.stdio;
struct Person {
string name;
float income;
On Friday, 27 December 2019 at 18:51:31 UTC, Adam D. Ruppe wrote:
On Friday, 27 December 2019 at 18:49:32 UTC, Sjoerd Nijboer
wrote:
Should concatenating the list and mixing that in work too?
yeah that'd work too. As long as all the overloads are coming
from the same source, D allows it.
On Friday, 27 December 2019 at 18:49:32 UTC, Sjoerd Nijboer wrote:
Should concatenating the list and mixing that in work too?
yeah that'd work too. As long as all the overloads are coming
from the same source, D allows it.
but if you add something manually in the struct then you have two
On Friday, 27 December 2019 at 18:34:49 UTC, Adam D. Ruppe wrote:
On Friday, 27 December 2019 at 18:22:10 UTC, Sjoerd Nijboer
wrote:
When calling the mixin directly instead of through the
template mixin it breaks with thesame error message.
What exactly did you do here?
I meant to say that
);
}
}
works for me...
I don't know if this an actual compiler bug or if this is me
not properly understanding D.
This is a case of the function hijacking rules biting you:
https://dlang.org/articles/hijack.html
template mixins take things in two different scopes:
mix!one_string
mix
e
mixin it breaks with thesame error message.
I don't know if this an actual compiler bug or if this is me not
properly understanding D.
I'm using DMD64 D Compiler v2.089.1
Any help is appreciated.
are right. The implementation does not do what the specs
tell here.
I filed a bug report:
https://issues.dlang.org/show_bug.cgi?id=20449
Thank you!
.
I filed a bug report:
https://issues.dlang.org/show_bug.cgi?id=20449
On Saturday, 14 December 2019 at 07:44:37 UTC, berni44 wrote:
On Saturday, 14 December 2019 at 07:09:30 UTC, Tobias Pankrath
wrote:
void main()
{
auto x = 9223372036854775808; // long.max + 1
}
You need to tell, that this is an unsigned long literal, else
the compiler treats it as an
On Saturday, 14 December 2019 at 07:09:30 UTC, Tobias Pankrath
wrote:
void main()
{
auto x = 9223372036854775808; // long.max + 1
}
You need to tell, that this is an unsigned long literal, else the
compiler treats it as an int:
void main()
{
auto x = 9223372036854775808UL; //
void main()
{
auto x = 9223372036854775808; // long.max + 1
}
onlineapp.d(3): Error: signed integer overflow
According to spec x should be of type ulong and this should
compile? It indeed compiles if I add the uL postfix.
Is this a bug or indented behaviour?
On Thursday, 12 December 2019 at 06:23:31 UTC, Basile B. wrote:
Still worth opening an issue.
https://issues.dlang.org/show_bug.cgi?id=20443
Thanks, Basile. I've added additional information from the github
thread where the sumtype author helpfully looked into the problem.
On Sunday, 8 December 2019 at 18:13:59 UTC, DanielG wrote:
On Sunday, 8 December 2019 at 18:01:03 UTC, Steven
Schveighoffer wrote:
Yes, if it can compile when you move things around, and the
result is *correct* (very important characteristic)
Indeed, everything's working as intended when
On Sunday, 8 December 2019 at 18:01:03 UTC, Steven Schveighoffer
wrote:
Yes, if it can compile when you move things around, and the
result is *correct* (very important characteristic)
Indeed, everything's working as intended when rearranged.
Thanks!
that can be changed to
make it work - neither seemingly related to the error at hand.
Yes, if it can compile when you move things around, and the result is
*correct* (very important characteristic), then it's definitely a bug.
There should be no ordering requirements for module-level code.
-Steve
- neither seemingly related
to the error at hand.
Just double-checking before I file a bug for this:
--
import sumtype;
// DMD 2.089.0-dirty (also v2.087.1)
// app.d(18,13): Error: struct
sumtype.SumType!(CallbackType1).SumType is not copyable because
(1);
}
The question is in the comment in the code. Is that intentional
or a bug?
It's a bug - filed as
https://issues.dlang.org/show_bug.cgi?id=20341.
However, note that typeof(this) inside funcTempl() is different
from X, so that inside helper(), X will not be the same as in
funcTempl
. Is that intentional
or a bug?
On Sunday, 21 April 2019 at 16:20:51 UTC, WebFreak001 wrote:
I'm trying to GC profile serve-d which uses a lot of fibers
potentially also across some threads and some threads doing
some dedicated work, however -profile=gc doesn't seem to work
properly. It logs `shared static this` calls and
On 08/16/2019 02:07 PM, Andrey Zherikov wrote:
But:
- if I change line (1) to `auto args = ["app", "--foo", "foo", "--bar",
"bar"];` then this code works.
- if I remove line (2) then this code works.
Yes, it's a bug.
Another workarou
Here is the code I have which doesn't work:
```
string[] foo;
string[] bar;
auto args = ["app", "--bar", "bar", "--foo", "foo"]; // (1)
import std.getopt;
getopt(args,
std.getopt.config.stopOnFirstNonOption, // (2)
"foo", ,
"bar", );
```
The error I see:
On Tuesday, 23 July 2019 at 00:54:08 UTC, aliak wrote:
On Tuesday, 23 July 2019 at 00:36:49 UTC, Exil wrote:
auto ref get(T)(W!T value) {
return value.front;
}
You're returning a reference to a temporary that gets deleted
at the end of the function's scope. The "auto ref" here will
be a
On Tuesday, 23 July 2019 at 00:36:49 UTC, Exil wrote:
auto ref get(T)(W!T value) {
return value.front;
}
You're returning a reference to a temporary that gets deleted
at the end of the function's scope. The "auto ref" here will be
a "ref".
. oh ... shit you're right.
Ok so this
auto ref get(T)(W!T value) {
return value.front;
}
You're returning a reference to a temporary that gets deleted at
the end of the function's scope. The "auto ref" here will be a
"ref".
Hi,
so I had this weird bug that was driving me crazy and only
segfaulted with ldc in release build - (I'm using ldc 1.16.0).
This is the code that segfaults. All parts seem to be necessary
for it to happen, or at least I think so. I've gone in circles
minimizing so I've probably missed
On Saturday, 20 July 2019 at 14:19:08 UTC, Adam D. Ruppe wrote:
Like the other person said, try/catch turns throws to nothrow.
The `debug` keyword disables pure checks. Those make this easy
without any mixin or wrappers/casts at all.
But even if you did want to do the mixin route, look at
On Saturday, 20 July 2019 at 09:01:21 UTC, Newbie2019 wrote:
I want to cast std.stdio : writefln into pure function pointer,
so I can call it from debug pure function.
Like the other person said, try/catch turns throws to nothrow.
The `debug` keyword disables pure checks. Those make this easy
On Saturday, 20 July 2019 at 09:01:47 UTC, Newbie2019 wrote:
On Saturday, 20 July 2019 at 09:01:21 UTC, Newbie2019 wrote:
I want to cast std.stdio : writefln into pure function
pointer, so I can call it from debug pure function. is there
a way to work around the pure check for call writefln
On Saturday, 20 July 2019 at 09:01:21 UTC, Newbie2019 wrote:
I want to cast std.stdio : writefln into pure function pointer,
so I can call it from debug pure function. is there a way to
work around the pure check for call writefln ?
nothrow check, not pure.
On Saturday, 20 July 2019 at 06:43:03 UTC, user1234 wrote:
use `__traits(identifier)` instead of `.stringof`, see
https://dlang.org/spec/traits.html#identifier.
as explained this is not a new bug, not even a bug according to
me.
I want to cast std.stdio : writefln into pure function
shared immutable " ~ N
~ "_P " ~ P ~"= cast(" ~ N ~ "_P) &" ~ N ~ " ;" ;
}
use `__traits(identifier)` instead of `.stringof`, see
https://dlang.org/spec/traits.html#identifier.
as explained this is not a new bug, not even a bug according to
me.
On Saturday, 20 July 2019 at 04:18:15 UTC, Adam D. Ruppe wrote:
show me what you're doing now and I'll see which case it is.
Most the time I see these, the code is significantly simplified
and bugs fixed by removing the usages of these strings..
I want to do this in betterC:
template
On Saturday, 20 July 2019 at 04:10:53 UTC, Newbie2019 wrote:
I may not fully understand why I can done it without
identifier.stringof
show me what you're doing now and I'll see which case it is. Most
the time I see these, the code is significantly simplified and
bugs fixed by removing the
On Saturday, 20 July 2019 at 03:58:36 UTC, Adam D. Ruppe wrote:
You should never actually need that! What is your use case?
In most cases I see people doing .stringof, the correct
solution is to simply... not. Use the local name directly.
If you do need the name - and the only cases for this
On Saturday, 20 July 2019 at 03:31:41 UTC, Newbie2019 wrote:
template Test(alias T){
pragma(msg, T.stringof);
Believe it or not, but this can result in the function being
called. This is D's optional parenthesis feature, to do simple
property syntax.
Not a bug.
I want get
template Test(alias T){
pragma(msg, T.stringof);
enum Test = T.stringof;
}
string t1;
void t2(){}
void t3(string s){}
extern(C) void main(){
enum x1 = Test!(t1); // ok
enum x2 = Test!(t2); // expect t2, but get t2()
enum x3 = Test!(t3); //Error:
On Friday, 14 June 2019 at 05:35:05 UTC, Amex wrote:
I used it to avoid having to write bar twice or use a flag but
it's not working... I see no reason why it should not work.
scope(exit) is suppose to execute the block at the end of the
function call, right?
No, a scope guard executes at
void foo()
{
void bar() { foo; }
switch
case: scope(exit) { do } break
bar;
}
fails to execute do
void foo()
{
void bar() { foo; }
switch
case: bar; do return;
bar;
}
does work... yet there is no difference except the scope exit.
In my code it is if do
rrectly with structs that have copy
> constructors). There should be no need to rename the trait, just update
> it, and whether it uses the name "elaborate" or "non-trivial" is pretty
> much irrelevant. Personally, I probably would have chosen hasNonTrivial
>
On Sunday, June 2, 2019 8:32:16 AM MDT Paul Backus via Digitalmars-d-learn
wrote:
> On Sunday, 2 June 2019 at 06:59:02 UTC, Jonathan M Davis wrote:
> > Almost certainly, hasElaborateCopyConstructor should be updated
> > to test for both postblit constructors and copy constructors,
> > since its
On Sunday, 2 June 2019 at 14:44:47 UTC, H. S. Teoh wrote:
On Sun, Jun 02, 2019 at 02:32:16PM +, Paul Backus via
Digitalmars-d-learn wrote: [...]
If std.v2 ever materializes, we'll have an opportunity to fix
papercuts like this. Until then, my preferred workaround is to
use a renaming
On Sun, Jun 02, 2019 at 02:32:16PM +, Paul Backus via Digitalmars-d-learn
wrote:
[...]
> If std.v2 ever materializes, we'll have an opportunity to fix
> papercuts like this. Until then, my preferred workaround is to use a
> renaming import:
>
> import std.traits: hasNontrivialCopy =
On Sunday, 2 June 2019 at 06:59:02 UTC, Jonathan M Davis wrote:
Almost certainly, hasElaborateCopyConstructor should be updated
to test for both postblit constructors and copy constructors,
since its purpose is to test for whether the type has a
user-defined copying function [...] Whether
On Saturday, June 1, 2019 5:29:08 PM MDT SrMordred via Digitalmars-d-learn
wrote:
> On Saturday, 1 June 2019 at 21:39:33 UTC, SImen Kjærås wrote:
> > On Saturday, 1 June 2019 at 21:05:32 UTC, SrMordred wrote:
> >
> > hasElaborateCopyConstructor checks if the type defines a
> > postblit[0].
>
>
On Sunday, 2 June 2019 at 04:02:08 UTC, Paul Backus wrote:
On Saturday, 1 June 2019 at 23:29:08 UTC, SrMordred wrote:
On Saturday, 1 June 2019 at 21:39:33 UTC, SImen Kjærås wrote:
On Saturday, 1 June 2019 at 21:05:32 UTC, SrMordred wrote:
Haven't tested it extensively, so use at your own
On Saturday, 1 June 2019 at 23:29:08 UTC, SrMordred wrote:
On Saturday, 1 June 2019 at 21:39:33 UTC, SImen Kjærås wrote:
On Saturday, 1 June 2019 at 21:05:32 UTC, SrMordred wrote:
hasElaborateCopyConstructor checks if the type defines a
postblit[0].
Yes, I know this.
But since dmd 2.086
On Saturday, 1 June 2019 at 21:39:33 UTC, SImen Kjærås wrote:
On Saturday, 1 June 2019 at 21:05:32 UTC, SrMordred wrote:
hasElaborateCopyConstructor checks if the type defines a
postblit[0].
Yes, I know this.
But since dmd 2.086 we have copy ctors:
On Saturday, 1 June 2019 at 21:05:32 UTC, SrMordred wrote:
import std.traits;
struct T { this(ref return scope T other){} }
pragma(msg, hasElaborateCopyConstructor!T); //false
hasElaborateCopyConstructor checks if the type defines a
postblit[0]. That is, a function called this(this).
import std.traits;
struct T { this(ref return scope T other){} }
pragma(msg, hasElaborateCopyConstructor!T); //false
I'm trying to GC profile serve-d which uses a lot of fibers
potentially also across some threads and some threads doing some
dedicated work, however -profile=gc doesn't seem to work
properly. It logs `shared static this` calls and some methods,
however none of the actual stuff is in there (and
traight-up bug to me. I don't see the difference
between those 3 calls.
-Steve
pen, but I believe static if works here
without issue. If so this means that it is a bug. Maybe compiles
can have handle certain primitives(such as bools here) but not
others(such as tuples in the main case)?
It would make little sense to be forced to use a temp variable:
static if (__traits(compil
On 2019-04-11 20:13, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes ~=
There seems to be absolutely no reason why this code would fail with the
ing
works. The whole point of the static if is to let the foreach work.
Both are only dependent on
__traits(getAttributes, T)
So if that can't compile then how could the foreach work?
https://run.dlang.io/is/WlXCIZ
Seems like a bug to me.
These all work:
@(3) int a;
static assert(__trait
On Friday, 12 April 2019 at 00:02:36 UTC, Seb wrote:
On Thursday, 11 April 2019 at 23:55:18 UTC, Alex wrote:
to judge people objectively. This isn't a nursery school and
we are not 3 year olds...
Exactly. So start behaving like a grown-up and professional.
When you ask someone for help on
On Thursday, 11 April 2019 at 23:55:18 UTC, Alex wrote:
to judge people objectively. This isn't a nursery school and we
are not 3 year olds...
Exactly. So start behaving like a grown-up and professional.
When you ask someone for help on the street, do you curse at him
too?
On Thursday, 11 April 2019 at 23:04:46 UTC, Mike Parker wrote:
On Thursday, 11 April 2019 at 22:41:32 UTC, Alex wrote:
Seriously? Do you think you have ESP? Your code isn't even
close to was talking about ;/
Here is is updated that shows the error. You seem to fail to
understand that it
On Thursday, 11 April 2019 at 22:41:32 UTC, Alex wrote:
Seriously? Do you think you have ESP? Your code isn't even
close to was talking about ;/
Here is is updated that shows the error. You seem to fail to
understand that it is impossible for it to be my code.
If you continue to attack
On Thursday, 11 April 2019 at 19:42:05 UTC, Steven Schveighoffer
wrote:
On 4/11/19 2:13 PM, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes
~=
On Thursday, 11 April 2019 at 20:49:45 UTC, bauss wrote:
On Thursday, 11 April 2019 at 18:13:48 UTC, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes
On Thursday, 11 April 2019 at 18:13:48 UTC, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes ~=
There seems to be absolutely no reason why this code
On 4/11/19 2:13 PM, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes ~=
There seems to be absolutely no reason why this code would fail with the
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes ~=
There seems to be absolutely no reason why this code would fail
with the static if but pass without it but in
On Friday, 5 April 2019 at 22:08:50 UTC, Adam D. Ruppe wrote:
Weird combination of cases that maybe should be illegal.
It errors with the highly descriptive errormessage:
app.obj(app)
Error 42: Symbol Undefined __D8mymodule3BarFZ3fooMFZCQx3Foo
Error: linker exited with status 1
On Friday, 5 April 2019 at 21:59:35 UTC, Sjoerd Nijboer wrote:
Foo Bar()
{
Foo foo();
It looks like the compiler is treating that as a function
prototype without a body (that just happens to be nested in
another function).
return foo;
And then, this foo is given the
module mymodule;
class Foo{}
Foo Bar()
{
Foo foo();
return foo;
}
int main()
{
auto foo = Bar();
return 0;
}
This code doesn't compile with a linker error that there's a
missing symbol for `Foo Bar()` on windows.
After all, `Foo foo();` isn't legitimate
On Saturday, 30 March 2019 at 00:44:31 UTC, Alex wrote:
On Saturday, 30 March 2019 at 00:06:23 UTC, H. S. Teoh wrote:
On Fri, Mar 29, 2019 at 11:44:35PM +, Alex via
Digitalmars-d-learn wrote:
interface iBase
{
iBase fooBase(iBase);
}
class cBase : iBase
{
cBase
On Saturday, 30 March 2019 at 00:06:23 UTC, H. S. Teoh wrote:
On Fri, Mar 29, 2019 at 11:44:35PM +, Alex via
Digitalmars-d-learn wrote:
interface iBase
{
iBase fooBase(iBase);
}
class cBase : iBase
{
cBase fooBase(cBase c) { return c; }
}
cBase.fooBase should be a valid
On Fri, Mar 29, 2019 at 11:44:35PM +, Alex via Digitalmars-d-learn wrote:
> interface iBase
> {
> iBase fooBase(iBase);
> }
>
>
> class cBase : iBase
> {
> cBase fooBase(cBase c) { return c; }
>
> }
>
> cBase.fooBase should be a valid override of iBase.fooBase because they
On Friday, 29 March 2019 at 23:44:35 UTC, Alex wrote:
> interface iBase
> {
> iBase fooBase(iBase);
> }
>
>
> class cBase : iBase
> {
> cBase fooBase(cBase c) { return c; }
>
> }
>
> cBase.fooBase should be a valid override of iBase.fooBase
> because
> they are the same type!
interface iBase
{
iBase fooBase(iBase);
}
class cBase : iBase
{
cBase fooBase(cBase c) { return c; }
}
cBase.fooBase should be a valid override of iBase.fooBase because
they are the same type! cBase is a super type so it contains
everything iBase contains and maybe
On Thursday, 14 March 2019 at 19:46:30 UTC, spir wrote:
But the doc (the language ref for the matter) should definitely
say what you just explained above, shouldn't they?
Well arguably, the spec should detail the language semantics
formally and not just be a description of the reference
On 14/03/2019 15:52, H. S. Teoh via Digitalmars-d-learn wrote:
On Thu, Mar 14, 2019 at 03:22:52PM +0100, spir via Digitalmars-d-learn wrote:
https://dlang.org/spec/hash-map.html#static_initialization:
immutable long[string] aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];
==> Error:
On Thursday, 14 March 2019 at 14:47:18 UTC, Adam D. Ruppe wrote:
On Thursday, 14 March 2019 at 14:22:52 UTC, spir wrote:
https://dlang.org/spec/hash-map.html#static_initialization:
Well, bug in implementation. That is *supposed* to work, but
the compiler never implemented it.
The docs
On Thu, Mar 14, 2019 at 03:22:52PM +0100, spir via Digitalmars-d-learn wrote:
> https://dlang.org/spec/hash-map.html#static_initialization:
>
> immutable long[string] aa = [
> "foo": 5,
> "bar": 10,
> "baz": 2000
> ];
>
> ==> Error: non-constant expression `["foo":5L, "bar":10L,
On Thursday, 14 March 2019 at 14:22:52 UTC, spir wrote:
https://dlang.org/spec/hash-map.html#static_initialization:
Well, bug in implementation. That is *supposed* to work, but the
compiler never implemented it.
The docs really should point out this fact explicitly, though.
On Thursday, 14 March 2019 at 14:22:52 UTC, spir wrote:
https://dlang.org/spec/hash-map.html#static_initialization:
immutable long[string] aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];
If I'm right, you can't use this syntax with global array. Insted
this works:
void main()
{
201 - 300 of 1912 matches
Mail list logo
