I have a container which provides access to data via a handle.
For book keeping I calculate some bitmasks.
Previously, when the handle type as well as the constants were
uint, everything compiled fine.
Today I added a template parameter to be able to specify the
handle type and I ran into this p
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.
bu
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
so
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 t
);
}
}
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_strin
directly instead of through the template
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.
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 rearr
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!
On 12/8/19 11:43 AM, DanielG wrote:
I dustmite'd down my problem code, and it seems just changing the order
of declarations makes the error go away. Specifically, moving a class
declaration from the bottom of the file, to the top, allows it to
compile. I also commented on two other things that
I dustmite'd down my problem code, and it seems just changing the
order of declarations makes the error go away. Specifically,
moving a class declaration from the bottom of the file, to the
top, allows it to compile. I also commented on two other things
that can be changed to make it work - nei
port off_t not found
I cannot explain this error, because off_t is defined in both
cases of the static if.
Even if I change it to:
static if ( true )
alias long off_t;
I get the same error. Is this a compiler bug?
Kind regards
André
and some doc:
http://dlang.org/spec/function.html#function-inheritance
On Wed, Aug 16, 2017 at 7:45 AM, Daniel Kozak wrote:
> No it is not a bug, there is no s() in B, you can fix this by adding:
>
> alias s = A.s;
>
> to class B
>
> On Wed, Aug 16, 2017 at 7:21 AM, apz28 via Digitalmars-d-learn
No it is not a bug, there is no s() in B, you can fix this by adding:
alias s = A.s;
to class B
On Wed, Aug 16, 2017 at 7:21 AM, apz28 via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> abstract class A
> {
> string _s;
>
> @property:
> final string s()
>
abstract class A
{
string _s;
@property:
final string s()
{
return _s;
}
A s(string x)
{
_s = x;
return this;
}
}
class B : A
{
@property:
final override A s(string x)
On Wednesday, 22 March 2017 at 14:06:56 UTC, Atila Neves wrote:
isInputRange looks like this:
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
isInputRange looks like this:
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront; // can invoke popFront()
auto h = r.f
On Tuesday, 28 October 2014 at 08:36:07 UTC, Szymon Gatner wrote:
On Monday, 27 October 2014 at 18:42:11 UTC, Marc Schütz wrote:
On Monday, 27 October 2014 at 16:58:56 UTC, Szymon Gatner
wrote:
On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote:
On Monday, 27 October 2014 at 12:40:17
On Monday, 27 October 2014 at 18:42:11 UTC, Marc Schütz wrote:
On Monday, 27 October 2014 at 16:58:56 UTC, Szymon Gatner wrote:
On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote:
On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh
wrote:
On 27/10/14 11:31, Szymon Gatner wro
On Monday, 27 October 2014 at 16:58:56 UTC, Szymon Gatner wrote:
On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote:
On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh
wrote:
On 27/10/14 11:31, Szymon Gatner wrote:
Right, sorry. Tho I admit I made assumptions since that was
On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote:
On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh
wrote:
On 27/10/14 11:31, Szymon Gatner wrote:
Right, sorry. Tho I admit I made assumptions since that was
not the full
code.
I've opened a bug. It has a fully containe
On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh wrote:
On 27/10/14 11:31, Szymon Gatner wrote:
Right, sorry. Tho I admit I made assumptions since that was
not the full
code.
I've opened a bug. It has a fully contained sample (that does
not, in fact, implement smartptr).
https:
On 27/10/14 11:31, Szymon Gatner wrote:
Right, sorry. Tho I admit I made assumptions since that was not the full
code.
I've opened a bug. It has a fully contained sample (that does not, in
fact, implement smartptr).
https://issues.dlang.org/show_bug.cgi?id=13661
On Monday, 27 October 2014 at 09:21:14 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 27 Oct 2014 09:11:33 +
Szymon Gatner via Digitalmars-d-learn
wrote:
You have created dynamic array of SmartPtrs.
nope. it's stack-allocated array.
Right, sorry. Tho I admit I made assumptions since
On Mon, 27 Oct 2014 09:11:33 +
Szymon Gatner via Digitalmars-d-learn
wrote:
> You have created dynamic array of SmartPtrs.
nope. it's stack-allocated array.
signature.asc
Description: PGP signature
dmd v2.065
Switching the init line to "array[] = SmartPtr!Foo.init" makes
the second assert pass.
To the best of my understanding, "array = array.init" should
always be equivalent to "array[] = typeof(array[0]).init" for
static arrays. Am I missing something? Is
is definitely compiler bug. if dmd insists on
postbliting, it should at least call destructors for all array
elements, not only for the first one four times. ;-)
signature.asc
Description: PGP signature
uot; makes the
second assert pass.
To the best of my understanding, "array = array.init" should always be
equivalent to "array[] = typeof(array[0]).init" for static arrays. Am I
missing something? Is this a compiler bug?
Thanks,
Shachar
no one any ideas?
well, i filed two bug reports for now:
https://d.puremagic.com/issues/show_bug.cgi?id=12532
https://d.puremagic.com/issues/show_bug.cgi?id=12533
d __error stuff.
so am i being stupid or is it a compiler bug?
cheers,
det
===CODE===
module demo;
template valid(string mem){
pragma(msg, "instantiation of valid with: "~mem);
static if( !__traits( compiles, mixin(mem) ) ){
enum valid = false;
}else{
Yes, it's strange. Using alias doesn't lead to this.
Oh, i see.
Great thanks!
On Sunday, 9 June 2013 at 13:37:45 UTC, Temtaime wrote:
Hello guys!
It seems that it is bug. And critical for me.
http://dpaste.1azy.net/b93f5776
Regards.
I don't know whether it's a bug, but I managed to reduce the error
to the following code (removing __traits code):
import std.stdio;
On Sunday, 9 June 2013 at 13:37:45 UTC, Temtaime wrote:
Hello guys!
It seems that it is bug. And critical for me.
http://dpaste.1azy.net/b93f5776
Regards.
The code should be rejected. It's a compiler bug.
But, you can do what you want as follows.
import std.stdio, std.typetuple;
str
Hello guys!
It seems that it is bug. And critical for me.
http://dpaste.1azy.net/b93f5776
Regards.
Ali Çehreli:
The best thing to do is to forget about the -property
switch. I did about a year ago and never looked back. :)
But the whole issue of -property was a partial failure for the D
community and D designers. Several threads, hundreds of posts,
and I see no clear directives or solutio
On Friday, May 31, 2013 08:27:19 Ali Çehreli wrote:
> I think it is the same issue with non-templated functions. The best
> thing to do is to forget about the -property switch. I did about a year
> ago and never looked back. :)
Given the most recent discussions on @property, I think that it's a fo
On 05/31/2013 07:32 AM, rmc wrote:
> It is very common to use a function template without the call "()"
> expecting that it will be called.
Non-templated functions too.
> However with the latest compilers
> hibernated only compiles when one leaves out the -property dmd command
> line option.
I
Hi all,
Not sure if this is a bug so thought I'd post here.
It is very common to use a function template without the call
"()" expecting that it will be called. However with the latest
compilers hibernated only compiles when one leaves out the
-property dmd command line option.
The call:
ge
This is a compiler regression in 2.063 release.
http://d.puremagic.com/issues/show_bug.cgi?id=10197
Kenji Hara
Thanks for looking into it.
Stewart
On Wednesday, 29 May 2013 at 04:44:16 UTC, estew wrote:
Hi All,
I updated to dmd 2.063 today and all has been going smoothly
until I decided to try out msgpack.d. I got an error compiling
the msgpack.d unittest, so out of interest I decided to check
this using dmd2.062 and it compiled and ran
Here's a link to the msgpack.d source:
https://github.com/msgpack/msgpack-d/blob/master/src/msgpack.d
And the error is on line 3211, not 3215 as mentioned in the
previous post.
Thanks,
Stewart
Hi All,
I updated to dmd 2.063 today and all has been going smoothly
until I decided to try out msgpack.d. I got an error compiling
the msgpack.d unittest, so out of interest I decided to check
this using dmd2.062 and it compiled and ran fine.
I admit I don't really understand whether the co
On 05/18/2013 11:50 AM, bearophile wrote:> Timon Gehr:
>
>> It is trivial to catch them in the parser.
>
> So the question is: is it right to catch them all? :-)
I don't think so. Double underscores are reserved for the
"implementation", which includes the standard library. I don't think the
co
Timon Gehr:
It is trivial to catch them in the parser.
So the question is: is it right to catch them all? :-)
Bye,
bearophile
On 05/17/2013 07:19 PM, bearophile wrote:
Jonathan M Davis:
However, if it _never_ makes sense to declare a variable
beginning with two underscores, I don't know why the compiler wouldn't
forbid
it other than the fact that it probably inserts such variables prior
to when
it would do the semanti
On Friday, 17 May 2013 at 14:35:35 UTC, Maxim Fomin wrote:
If it alwalys a bad idea, compiler should not accept such code.
I'm pretty sure the answer is:
Compilers can have different extensions, it would be bad for a
compiler to reject code which is valid by another compiler.
That said, I d
On 05/17/2013 12:27 PM, Jonathan M Davis wrote:
> On Friday, May 17, 2013 19:19:46 bearophile wrote:
>> I think to answer this issue we need someone that knows more
>> about the DMD compiler (as Kenji Hara). I think that if we want
>> to forbid those variables in user code, then probably there is a
On Friday, 17 May 2013 at 17:08:31 UTC, Jonathan M Davis wrote:
On Friday, May 17, 2013 11:59:38 1100110 wrote:
On 05/17/2013 09:35 AM, Maxim Fomin wrote:
> If it alwalys a bad idea, compiler should not accept such
> code.
It is not the D way to forbid you from shooting yourself in
the foot.
On Friday, May 17, 2013 19:19:46 bearophile wrote:
> I think to answer this issue we need someone that knows more
> about the DMD compiler (as Kenji Hara). I think that if we want
> to forbid those variables in user code, then probably there is a
> way do to it.
Oh, I'm sure that it would be possi
Jonathan M Davis:
However, if it _never_ makes sense to declare a variable
beginning with two underscores, I don't know why the compiler
wouldn't forbid
it other than the fact that it probably inserts such variables
prior to when
it would do the semantic analysis to check whether variables
st
On Friday, May 17, 2013 11:59:38 1100110 wrote:
> On 05/17/2013 09:35 AM, Maxim Fomin wrote:
> > If it alwalys a bad idea, compiler should not accept such code.
>
> It is not the D way to forbid you from shooting yourself in the foot.
>
> goto, catch(Throwable th), there are plenty more examples.
On Friday, May 17, 2013 16:40:23 Temtaime wrote:
> Yes, i want to see 'undeclared variable' error, but the compiler
> omits function declaration instead.
>
> And why i shouldn't use __? I think it's ordinary identifier.
Identifiers begining with two underscores are reserved by the compiler, which
On 05/17/2013 09:35 AM, Maxim Fomin wrote:
> On Friday, 17 May 2013 at 14:12:10 UTC, Namespace wrote:
>> I don't see where k comes from?
>
> I think the point is that it comes from nowhere. Compiler incorectly
> omits two errors from output: "Error undefined indentifier" and
> "template instance e
On 05/17/2013 07:40 AM, Temtaime wrote:
Yes, i want to see 'undeclared variable' error, but the compiler omits
function declaration instead.
And why i shouldn't use __? I think it's ordinary identifier.
"Identifiers starting with __ (two underscores) are reserved."
http://dlang.org/le
On Friday, 17 May 2013 at 14:35:35 UTC, Maxim Fomin wrote:
On Friday, 17 May 2013 at 14:12:10 UTC, Namespace wrote:
I don't see where k comes from?
I think the point is that it comes from nowhere. Compiler
incorectly omits two errors from output: "Error undefined
indentifier" and "template i
Maxim Fomin:
If it alwalys a bad idea, compiler should not accept such code.
Ideally you are right. But I think sometimes you want to use
those reserved names... So I don't know.
Bye,
bearophile
Temtaime:
This code doesn't compiles with an error:
Error: 'b' is not of arithmetic type, it is a B
If i remove k++, then it's OK. It seems that compiler omitting
the function if there an error in it.
It's a bad error message, but it's correct, because k doesn't
exists. This error message i
Yes, i want to see 'undeclared variable' error, but the compiler
omits function declaration instead.
And why i shouldn't use __? I think it's ordinary identifier.
On Friday, 17 May 2013 at 14:12:10 UTC, Namespace wrote:
I don't see where k comes from?
I think the point is that it comes from nowhere. Compiler
incorectly omits two errors from output: "Error undefined
indentifier" and "template instance error instantiation". This
should go to bugzilla.
I don't see where k comes from?
And it's always a bad idea to prefix a variable with '__',
because this is reserved to the compiler.
struct A {
int opBinary(string op)(A) { k++; return 0; }
}
struct B {
A __a;
alias __a this;
}
void main() {
B b;
auto c = b * b;
}
This code doesn't compiles with an error:
Error: 'b' is not of arithmetic type, it is a B
If i remove k++, then it's OK. It seems
On Tuesday, 13 November 2012 at 12:31:26 UTC, Kenji Hara wrote:
This issue looks like bug8093.
http://d.puremagic.com/issues/show_bug.cgi?id=8093
And the code works correctly in git head (dmd2.061alpha).
Therefore, I think that the bug is fixed very recently.
Kenji Hara
Thanks for the resp
On Tuesday, 13 November 2012 at 08:50:16 UTC, Rob T wrote:
Hard to describe this problem, see code and read comments below.
class A
{
private int _v;
this( int a_v )
{
_v = a_v;
}
@property size_t length()
{
return 1;
}
int opApply( int delegate( r
Hard to describe this problem, see code and read comments below.
class A
{
private int _v;
this( int a_v )
{
_v = a_v;
}
@property size_t length()
{
return 1;
}
int opApply( int delegate( ref int a_v ) a_dg )
{
int result = 0;
for ( u
On Sunday, January 29, 2012 08:43:54 sclytrack wrote:
> Prior to filing the bug I tried to compile dmd from source.
> I have now succeeded. The only problem I had was a missing
> symbolic link libstdc++.so and this in Ubuntu 11.10. So
> I just created it.
>
> /usr/lib32/libstdc++.so -> /usr/lib/i3
Prior to filing the bug I tried to compile dmd from source.
I have now succeeded. The only problem I had was a missing
symbolic link libstdc++.so and this in Ubuntu 11.10. So
I just created it.
/usr/lib32/libstdc++.so -> /usr/lib/i386-linux-gnu/libstdc++.so.6
Then "make -f posix" and in the dmd
On Sat, Jan 28, 2012 at 2:04 PM, sclytrack wrote:
>
>
> Now I've waisted Walter's precious time.
> I feel so sad now :-(
>
I should have made a post about the fact that I had already bug
reported it, but I forgot. Sorry.
Now I've waisted Walter's precious time.
I feel so sad now :-(
On 01/28/2012 07:49 PM, Caligo wrote:
I've already reported, and it's been fixed in the latest:
http://d.puremagic.com/issues/show_bug.cgi?id=7376
On Sat, Jan 28, 2012 at 9:56 AM, sclytrack wrote:
On 01/25/2012 01:12 AM, Tim
I've already reported, and it's been fixed in the latest:
http://d.puremagic.com/issues/show_bug.cgi?id=7376
On Sat, Jan 28, 2012 at 9:56 AM, sclytrack wrote:
> On 01/25/2012 01:12 AM, Timon Gehr wrote:
>>
>> On 01/24/2012 10:28 PM, %u wrote:
>>>
>>> Shouldn't this go into 'digitalmars.D' ?
>>
On 01/28/2012 04:56 PM, sclytrack wrote:
On 01/25/2012 01:12 AM, Timon Gehr wrote:
On 01/24/2012 10:28 PM, %u wrote:
Shouldn't this go into 'digitalmars.D' ?
It should go straight to the bug tracker.
Issue 7391 - floating wtf dmd 2.057 64
Thanks!
On 01/25/2012 01:12 AM, Timon Gehr wrote:
On 01/24/2012 10:28 PM, %u wrote:
Shouldn't this go into 'digitalmars.D' ?
It should go straight to the bug tracker.
Issue 7391 - floating wtf dmd 2.057 64
On 01/24/2012 10:28 PM, %u wrote:
Shouldn't this go into 'digitalmars.D' ?
It should go straight to the bug tracker.
Shouldn't this go into 'digitalmars.D' ?
Am 24.01.2012 19:13, schrieb Caligo:
How did you compile it? As in my original post, it matters how you
compile it. In this case (I'm on a 64-bit GNU/Linux system),
compiling with '-inline' doesn't trigger the bug.
im on win7 (64bit) - but the windows dmd2.057 isn't able to produce x64
code
How did you compile it? As in my original post, it matters how you
compile it. In this case (I'm on a 64-bit GNU/Linux system),
compiling with '-inline' doesn't trigger the bug.
Am 24.01.2012 18:49, schrieb sclytrack:
dmd 2.057 give this result under windows/32bit
calculate1:
1.5
1.5
calculate2:
1.5
1.5
calculate3:
1.5
1.5
so its seems to be an x64 compiler bug
Yes, I missed my lessons in clear communication
The spec doesn't mention anything about nested functions here.
This works
void foo(int[] a, int x) { };
void main()
{
int[] array;
foo(array, 3);
array.foo(3);
}
But this gives "undefined identifier module t.foo"
void main()
{
void foo(int[] a, int x) { };
78 matches
Mail list logo
