On Tuesday, 10 November 2015 at 15:44:26 UTC, ponce wrote:
Since assert(false) is special (cf.
http://p0nce.github.io/d-idioms/#assert%28false%29-is-special)
you can use the following construct to have always-on
assert(false) AKA assert(0) - is a part of this language that I
think it is
On Tuesday, 10 November 2015 at 13:09:09 UTC, Fyodor Ustinov
wrote:
Hi!
Is it possible when using the "-release" indicate that this one
in/out/invariant/assert should not to be disabled?
WBR,
Fyodor.
I don't quite get why you'd like to use -release if you are
paranoid enough to be
On Tuesday, 10 November 2015 at 20:46:14 UTC, cym13 wrote:
I don't quite get why you'd like to use -release if you are
paranoid enough to be afraid of assert(0)'s little difference
in behaviour. Could you give a realistic use case? At the very
least seeing why it is important to you can only
Hi!
Is it possible when using the "-release" indicate that this one
in/out/invariant/assert should not to be disabled?
WBR,
Fyodor.
On Tuesday, 6 October 2015 at 05:54:44 UTC, Jonathan M Davis
wrote:
It is by design, albeit undesirable. When SysTime was
originally written, it was impossible to have a default value
for a class reference other than null. So, unless SysTime was
going to take the performance hit of constantly
This code:
import std.stdio;
import std.datetime;
void main()
{
SysTime t = SysTime.init;
writeln(t);
}
results in segfault with dmd-2.068.2
Is it ok?
Backtrace:
#0 0x004733f3 in std.datetime.SysTime.adjTime() const ()
#1 0x004730b9 in
On Monday, October 05, 2015 18:12:06 tchaloupka via Digitalmars-d-learn wrote:
> This code:
>
> import std.stdio;
> import std.datetime;
>
> void main()
> {
> SysTime t = SysTime.init;
> writeln(t);
> }
>
> results in segfault with dmd-2.068.2
>
> Is it ok?
It is by design, albeit
fix - https://github.com/D-Programming-Language/phobos/pull/3524
On Monday, 29 June 2015 at 14:28:06 UTC, anonymous wrote:
On Monday, 29 June 2015 at 12:04:46 UTC, Jonathan M Davis wrote:
You haven't declared an immutable constructor, so you can't
construct an immutable Foo.
That's not what's happening. Constructing an immutable Foo
works just fine.
constructor were pure, then it could be used
to construct immutable objects even if it weren't immutable, but the default
constructor is neither pure nor immutable, and purity isn't inferred for
normal functions.
It might make sense as a feature request to request that a class' default
constructor be pure
On Monday, 29 June 2015 at 12:04:46 UTC, Jonathan M Davis wrote:
You haven't declared an immutable constructor, so you can't
construct an immutable Foo.
That's not what's happening. Constructing an immutable Foo works
just fine.
https://issues.dlang.org/show_bug.cgi?id=14751
I'd say bug, I think the array function is trying an optimization
it shouldn't be trying for immutable classes.
, and purity
isn't inferred for normal functions.
It might make sense as a feature request to request that a class'
default constructor be pure (assuming that its base class constructor
is pure), since theoretically, it should be able to be pure, but that
would be a change in the language. What
I don't see any reason why it should not compile.
import std.array;
import std.range;
import std.algorithm;
class Foo {
}
void main() {
auto result = iota(3).map!(i = new immutable Foo).array();
}
/usr/include/dmd/phobos/std/conv.d(4028): Error: cannot
implicitly convert expression
On Thursday, 14 May 2015 at 00:29:06 UTC, Dennis Ritchie wrote:
Why doesn't the compiler produces an error?
-
import std.stdio;
void main() {
writeln({});
}
-
http://ideone.com/qTZCAd
Somehow reminds me of this lambda:
On Friday, 15 May 2015 at 08:44:41 UTC, Ivan Kazmenko wrote:
Somehow reminds me of this lambda:
https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d#L127-L128
Maybe it generally blocks for initialization of variables:
On 05/14/2015 03:39 PM, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 21:55:40 UTC, Alex Parrill wrote:
On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote:
You told it to output a function literal, so it did.
Yes,
On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote:
You told it to output a function literal, so it did.
Yes, but it would be logical to deduce something like:
-
writeln({}); // prints literal[{}]
Or the compiler
On Thursday, 14 May 2015 at 21:55:40 UTC, Alex Parrill wrote:
On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote:
You told it to output a function literal, so it did.
Yes, but it would be logical to deduce something
On Thursday, 14 May 2015 at 22:55:43 UTC, Ali Çehreli wrote:
Yes, it is weird but that value happens to be the address of
the function. Here is another test:
import std.stdio;
void foo() pure nothrow @nogc @safe
{}
void main()
{
void printInfo(T)(T t)
{
writefln(%s %s,
On Thursday, 14 May 2015 at 00:29:06 UTC, Dennis Ritchie wrote:
Why doesn't the compiler produces an error?
-
import std.stdio;
void main() {
writeln({});
}
-
http://ideone.com/qTZCAd
You told it to output a function literal, so it did.
(That or you told it to output a
Turns out that I can put into the function writeln almost any
design language:
-
import std.stdio;
void main() {
writeln( { int n = 5; } );
}
-
http://ideone.com/Rp7gZ2
On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote:
You told it to output a function literal, so it did.
Yes, but it would be logical to deduce something like:
-
writeln({}); // prints literal[{}]
Or the compiler will not be able to distinguish the literal from
the ordinary
Why doesn't the compiler produces an error?
-
import std.stdio;
void main() {
writeln({});
}
-
http://ideone.com/qTZCAd
On 05/10/2015 10:18 AM, Jack Applegame wrote:
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
Error: function B.test () is not callable using argument types (int)
It is a concept called name
On Sunday, May 10, 2015 10:48:33 Ali Çehreli via Digitalmars-d-learn wrote:
On 05/10/2015 10:18 AM, Jack Applegame wrote:
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
Jack Applegame wrote:
test(10); // error
One can import the declaration by using an alias:
class A {
void test(int) {}
}
class B : A {
alias test= super.test;
void test() {
super.test(1); // compiles
test(10); // compiles
}
}
-manfred
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
Error: function B.test () is not callable using argument types
(int)
Ok, it's a feature. Thanks.
that function is defined
instead. I'm not sure if we need updated output from dmd, or if this is
all ddox, so I don't know where to file this feature request. Does one
file ddox requests on issues.dlang.org?
-Steve
This had actually already been implemented, but obviously got broken at
some point. I'll
updated output from dmd, or if this is
all ddox, so I don't know where to file this feature request. Does one
file ddox requests on issues.dlang.org?
-Steve
On Saturday, December 13, 2014 02:34:21 Jeremy DeHaan via Digitalmars-d-learn
wrote:
Is this on purpose? Granted, I almost never use interface files,
but I had a whim to use them for what I was working on today.
Everything worked fine when I renamed the file to package.d, but
apparently
Is this on purpose? Granted, I almost never use interface files,
but I had a whim to use them for what I was working on today.
Everything worked fine when I renamed the file to package.d, but
apparently package.di is not acceptible.
When using the typeid expression on a instance of an interface it
gives the type of the interface not the type of the underlying
object. Is this intended or is it a bug?
interface I { }
class A : I { }
class B : A { }
unittest
{
A a = new A();
B b = new B();
writeln(typeid(a));
On Friday, 20 December 2013 at 21:21:16 UTC, TheFlyingFiddle
wrote:
Is this intended or is it a bug?
Intended, because an interface is not necessarily an Object. It
might also be a COM object or a C++ object, and the typeinfo may
not be available for them. (I think, maybe it would be from
is there a way to achieve this:
dmd -L-lfoo -L-lbar main.d
with a single call to -L to pass several linker options; something like:
dmd -L'-lfoo -lbar' main.d
except that won't work due to '' being treated as one argument.
Maybe something like:
dmd --L=' flag1 flag2' main.d
which would treat the
It is impossible to pack a structure with shared object into
tuple.
```
import std.concurrency;
import std.typecons;
class Foo {}
struct A {
shared Foo foo;
}
void main() {
auto a = tuple(new shared Foo); // ОК
auto b = tuple(A());// Error: static assert unable
On 8/27/13, Jack Applegame jappleg...@gmail.com wrote:
It is impossible to pack a structure with shared object into
tuple.
Bug. Please file it to bugzilla:
http://d.puremagic.com/issues/enter_bug.cgi?product=D
Thanks!
On Monday, 26 August 2013 at 23:04:24 UTC, Andrej Mitrovic wrote:
Bug. Please file it to bugzilla:
http://d.puremagic.com/issues/enter_bug.cgi?product=D
Thanks!
http://d.puremagic.com/issues/show_bug.cgi?id=10907
Well, how you can reduce the long ugly name in this case? In the
real function I mentioned it so many times.
void foo( S s )
{
auto local = this.bigUglyName;
auto b = s.bigUglyName;
writeln( bigUglyName (AKA local)=, local, b=, b );
}
:P
On Monday, 27 May 2013 at 10:17:01 UTC, Namespace wrote:
void foo( S s )
{
auto local = this.bigUglyName;
auto b = s.bigUglyName;
writeln( bigUglyName (AKA local)=, local, b=, b );
}
:P
By the way, yes. Thanks for that, I'm stupid today.
On Monday, 27 May 2013 at 10:07:49 UTC, mimi wrote:
Well, how you can reduce the long ugly name in this case? In
the real function I mentioned it so many times.
By not making the name ugly big.
On Monday, 27 May 2013 at 11:32:46 UTC, Maxim Fomin wrote:
On Monday, 27 May 2013 at 10:07:49 UTC, mimi wrote:
Well, how you can reduce the long ugly name in this case? In
the real function I mentioned it so many times.
By not making the name ugly big.
Other people do.
In addition,
import std.stdio;
struct S
{
int bigUglyName;
void foo( S s )
{
alias bigUglyName local;
alias s.bigUglyName b;
writeln( bigUglyName (AKA local)=, local, b=, b );
}
}
void main()
{
S s1;
S s2;
s1.bigUglyName = 1;
s2.bigUglyName = 2;
On Sunday, 26 May 2013 at 23:35:43 UTC, mimi wrote:
import std.stdio;
struct S
{
int bigUglyName;
void foo( S s )
{
alias bigUglyName local;
alias s.bigUglyName b;
writeln( bigUglyName (AKA local)=, local, b=, b );
}
}
void main()
{
S s1;
S
I don't know where that cast occurs but I wanted to state the
obvious: Operator ~ is defined only for arrays.
Would having it also work for individual units to make an array
be a plausible enhancement request? It would seem like a natural
use of the operator.
This is simple code to create all genetic combinations from two
organisms.
string[] mixGenes(string a, string b) {
string[] result;
foreach(i;0..2)
foreach(j;0..2)
foreach(k;2..4)
foreach(m;2..4)
This is simple code to create all genetic combinations from two
organisms.
string[] mixGenes(string a, string b) {
string[] result;
foreach(i;0..2)
foreach(j;0..2)
foreach(k;2..4)
foreach(m;2..4)
On 12/05/2012 09:30 AM, ixid wrote:
This is simple code to create all genetic combinations from two organisms.
string[] mixGenes(string a, string b) {
string[] result;
foreach(i;0..2)
foreach(j;0..2)
foreach(k;2..4)
foreach(m;2..4)
result ~= [a[i]] ~ [b[j]] ~ [a[k]] ~ [b[m]];
return result;
}
On 29/12/2011 19:09, Jacob Carlborg wrote:
snip excessive quote
Could druntime hook up on the atexit function to run destructors and similar
when the
program exits?
I'm not sure. Maybe it could be called upon to run static destructors and destruct
heap-allocated objects. But in order to
That should have been int main.
On Thursday, December 29, 2011 23:03:23 Ashish Myles wrote:
Since D
could conceivably implement a very safe exit() without an explicit use
of Exceptions to get around the catch Exception() {} problem you
mentioned above, does it make sense to request a safer exit() feature
for D?
And how
above, does it make sense to request a safer exit() feature
for D?
And how would it do that? The only way in the language to properly unwind the
stack without returning from each and every function is to throw an Exception.
If you wanted to do an exit function, it would somehow have to do
On Friday, December 30, 2011 10:45:43 Ashish Myles wrote:
Ok, now there are two issues here:
IMPLEMENTATION: Implementation of a safe_exit() without an explicit
Exception seems to be easy to do at the language level for a
single-threaded program -- you simply have a hidden/system class like,
Thanks, Jonathan, for your detailed answer.
Ashish
On Fri, Dec 30, 2011 at 1:41 PM, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Friday, December 30, 2011 10:45:43 Ashish Myles wrote:
Ok, now there are two issues here:
IMPLEMENTATION: Implementation of a safe_exit() without an explicit
On 2011-12-29 18:22, Jakob Ovrum wrote:
On Thursday, 29 December 2011 at 16:27:33 UTC, Ashish Myles wrote:
std.c.stdlib.exit() seems to break RAII. The code below tests this
both using a struct destructor and an explicit scope(exit) {}. Is
this an intentional feature or a bug?
import std.stdio
Probably the easiest thing to do is to throw a custom exception and
catch it somewhere in main() to return your status code. Unlike
exit(), throwing will take care of RAII stuff.
block),
would it be reasonable to do a feature request for a
D-language-supported exit()?
On Thursday, 29 December 2011 at 16:27:33 UTC, Ashish Myles wrote:
std.c.stdlib.exit() seems to break RAII. The code below tests
this
both using a struct destructor and an explicit scope(exit) {}.
Is
this an intentional feature or a bug?
import std.stdio;
import std.c.stdlib;
void main
On Thursday, 29 December 2011 at 17:22:33 UTC, Jakob Ovrum wrote:
Calling 'exit' doesn't properly shut down the D runtime either,
it's not just constructors.
I mean destructors*.
exit code, return the exit code in the catch block),
would it be reasonable to do a feature request for a
D-language-supported exit()?
Yeah, really. I'd been using the C exit() as well. Seems like a pretty
fundamental feature. :O
a custom
exception storing exit code, return the exit code in the catch block),
would it be reasonable to do a feature request for a
D-language-supported exit()?
A D exit function would have to do essentially the same thing as throw an
exception and catch it in main anyway. The only way
implement a very safe exit() without an explicit use
of Exceptions to get around the catch Exception() {} problem you
mentioned above, does it make sense to request a safer exit() feature
for D?
Ashish
bearophile , dans le message (digitalmars.D.learn:29532), a écrit :
Well, I don't understand the error it gives :-) Are you able to explain it to
me?
import std.stdio;
void main() {
int i = 1;
switch(i) {
case 0:
writeln(case 0);
goto
Not sure if this is a bug or as intended.
import std.stdio;
void main() {
int i = 1;
switch(i) {
case 0:
writeln(case 0);
goto default; // needed here
default:
writeln(default);
// But always falls through here
simendsjo Wrote:
Not sure if this is a bug or as intended.
The semantics of switch is a mess (example: see
http://d.puremagic.com/issues/show_bug.cgi?id=3820 ).
Mixing labels and switch cases seems a good way to create a bigger mess.
If I invert some things in your code I get an error...
On 14.09.2011 22:52, simendsjo wrote:
Not sure if this is a bug or as intended.
import std.stdio;
void main() {
int i = 1;
switch(i) {
case 0:
writeln(case 0);
goto default; // needed here
default:
writeln(default);
// But always falls through here
aLabel:
writeln(a label);
}
}
Label doesn't
On 09/14/2011 08:52 PM, simendsjo wrote:
Not sure if this is a bug or as intended.
import std.stdio;
void main() {
int i = 1;
switch(i) {
case 0:
writeln(case 0);
goto default; // needed here
default:
writeln(default);
// But always falls through here
aLabel:
writeln(a label);
}
}
This is as
On 09/14/2011 09:11 PM, bearophile wrote:
simendsjo Wrote:
Not sure if this is a bug or as intended.
The semantics of switch is a mess (example: see
http://d.puremagic.com/issues/show_bug.cgi?id=3820 ).
Mixing labels and switch cases seems a good way to create a bigger mess.
I think it is
Timon Gehr:
I think it is a bit mean to say the whole semantics is a mess,
The original C design is a mess with several traps, and successive things added
in D to the switch have increased the mess, they were designed from very narrow
points of view, with a lack of global vision:
1) The case
On 15.09.2011 0:51, bearophile wrote:
Timon Gehr:
I think it is a bit mean to say the whole semantics is a mess,
The original C design is a mess with several traps, and successive things added
in D to the switch have increased the mess, they were designed from very narrow
points of view,
On 09/14/2011 10:51 PM, bearophile wrote:
Timon Gehr:
I think it is a bit mean to say the whole semantics is a mess,
The original C design is a mess with several traps, and successive things added
in D to the switch have increased the mess, they were designed from very narrow
points of
Timon Gehr:
What would you suggest?
At the moment I suggest nothing, because the situation is set.
Case syntax was discussed a lot, by me too. I suggested to differentiate the
syntax, not using .. because in D they denote an interval open on the right.
'C switch' means 'jump table'. It
am dispatching in class!
writeln ( test2 ); // NOTHING :( But should return I am
Test class!
}
Is it a feature or a bug?
Best regards,
Damian Ziemba
Try to create the method:
const void toString(void delegate(const(char)[]) sink, string formatString)
{
sink(toString());
}
On Thu, 01 Sep 2011 07:56:49 +, Christophe wrote:
Try to create the method:
const void toString(void delegate(const(char)[]) sink, string
formatString) {
sink(toString());
}
Adding it as it is results in compiler error:
./quick.d(30): Error: function quick.Test2.toString ()
!
writeln ( test2.s() ); // I am dispatching in class!
writeln ( test2 ); // NOTHING :( But should return I am
Test class!
}
Is it a feature or a bug?
Best regards,
Damian Ziemba
static assert(isInputRange!Test);
static assert(isInputRange!Test2
On Thu, 01 Sep 2011 13:59:29 +0200, Timon Gehr wrote:
static assert(isInputRange!Test);
static assert(isInputRange!Test2);
toString is not shadowed, but the implementation of writeln assumes that
your types are an InputRange (they provide, by the means of opDispatch,
front(), empty() and
On 09/02/2011 12:09 AM, Damian Ziemba wrote:
On Thu, 01 Sep 2011 13:59:29 +0200, Timon Gehr wrote:
static assert(isInputRange!Test);
static assert(isInputRange!Test2);
toString is not shadowed, but the implementation of writeln assumes that
your types are an InputRange (they provide, by the
I am trying to build a struct with equality testing, using this code:
struct Foo
{
const bool opEquals(Foo f)
{
return true;
}
}
This gives me the error that the parameter should be of type ref const Foo.
Fine.
struct Foo
{
const bool opEquals(ref const Foo f)
{
On Monday, August 29, 2011 22:41:26 Sean Eskapp wrote:
I am trying to build a struct with equality testing, using this code:
struct Foo
{
const bool opEquals(Foo f)
{
return true;
}
}
This gives me the error that the parameter should be of type ref const
Foo.
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
On Monday, August 29, 2011 22:41:26 Sean Eskapp wrote:
I am trying to build a struct with equality testing, using this code:
struct Foo
{
const bool opEquals(Foo f)
{
return true;
}
}
This
you're *testing* D code ported
from C it would be so much more convenient if you can pass a char* to
writef() and use %s to treat it as a C string without having to go
through the trouble of writing to!string everywhere.
I feel uneasy with this feature. Basically, this means writef makes
Steven Schveighoffer:
This feature brings absolutely nothing to the table IMO.
Added as issue 5368.
Bye,
bearophile
, or any
combination of values which can be mapped to a constructor of that
class. It can be convenient sometimes.
While I understand some may consider this a nice feature, for me this is an
enormous bug. A great way toward code obfuscation. I like D among other reasons
because it's rather
spir:
While I understand some may consider this a nice feature, for me this is an
enormous bug. A great way toward code obfuscation. I like D among other
reasons because it's rather clear compared to other languages of the family.
The main problem here is that I have never felt the need
On 12/23/10, bearophile bearophileh...@lycos.com wrote:
spir:
While I understand some may consider this a nice feature, for me this is
an enormous bug. A great way toward code obfuscation. I like D among other
reasons because it's rather clear compared to other languages of the
family
bearophile wrote:
spir:
While I understand some may consider this a nice feature, for me this is an
enormous bug. A great way toward code obfuscation. I like D among other reasons
because it's rather clear compared to other languages of the family.
The main problem here is that I have
On Thu, 23 Dec 2010 12:34:45 -0500, Don nos...@nospam.com wrote:
bearophile wrote:
spir:
While I understand some may consider this a nice feature, for me this
is an enormous bug. A great way toward code obfuscation. I like D
among other reasons because it's rather clear compared to other
DMD 2.051 with -unittest:
import std.algorithm, std.range, std.stdio : writeln;
void main() {}
void average(double[]) { writeln(non-variadic); }
void average(double[]...) { writeln(variadic); }
unittest {
average(1.5); // writes variadic
}
On Wednesday, December 22, 2010 12:05:18 Andrej Mitrovic wrote:
DMD 2.051 with -unittest:
import std.algorithm, std.range, std.stdio : writeln;
void main() {}
void average(double[]) { writeln(non-variadic); }
void average(double[]...) { writeln(variadic); }
unittest {
I thought the variadic version would only take this type:
average([1.5], [2.5]);
So a variable number of *array* of doubles, not a variable number of doubles.
On 12/22/10, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Wednesday, December 22, 2010 12:05:18 Andrej Mitrovic wrote:
DMD 2.051
On Wed, 22 Dec 2010 15:46:01 -0500, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
I thought the variadic version would only take this type:
average([1.5], [2.5]);
So a variable number of *array* of doubles, not a variable number of
doubles.
No, that's not it.
T[] arg... is a
Oooh. That cought me off guard, sorry.
Thanks Steve.
On 12/22/10, Steven Schveighoffer schvei...@yahoo.com wrote:
On Wed, 22 Dec 2010 15:46:01 -0500, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
I thought the variadic version would only take this type:
average([1.5], [2.5]);
So a
On 12/22/10 15:06, Andrej Mitrovic wrote:
Oooh. That cought me off guard, sorry.
Thanks Steve.
I'll concede that the syntax can be odd at first, but it also enables
some interesting things. For example, this works:
class Foo {
this (int i, double f) { /*...*/ }
/*...*/
}
void
of whether you consider that a good or bad idea though, there's
no point in adding contracts into it. They don't add anything. If the
feature is supported by the class, then no exception gets thrown. If it
isn't, then an exception gets thrown. All adding asserts in preconditions
does is make
Lutger wrote:
Jonathan M Davis wrote:
Lutger wrote:
True, it only adds AssertError and that could be replaced with regular
asserts.
Thanks.
??? Regular asserts? When asserts in D fail, they throw an exception of
type AssertError. So, unless you're talking about explicitly
Is there such stuff available in D website? Or the only choice to quick check
what features are supported by D2 also supported by D1 is to go through the
spec?
Thanks in advance.
Regards,
Sam
101 - 200 of 202 matches
Mail list logo
