My final implementation:
http://dpaste.dzfl.pl/4d2a045a
Any suggestions?
Namespace:
I have this code, but it works not as expected:
http://dpaste.dzfl.pl/6ce5b4dd
I suggest to file a bug:
auto foo(bool b) {
final switch (b) {
case true:
return 10;
case false:
return 20.0;
}
}
void main() {
import std.stdio
On Tuesday, 11 September 2012 at 21:13:02 UTC, bearophile wrote:
Namespace:
I have this code, but it works not as expected:
http://dpaste.dzfl.pl/6ce5b4dd
I suggest to file a bug:
auto foo(bool b) {
final switch (b) {
case true:
return 10;
case false
11.09.2012 22:48, Ali Çehreli пишет:
return to!(ReturnType!(typeof(foo)))(42);
typeof(return)
See http://dlang.org/declaration.html#typeof
Anyway don't use it as a type of the first return. You will get:
---
Error: cannot use typeof(return) inside function foo with inferred
return
On Tuesday, September 11, 2012 23:31:43 Namespace wrote:
Sure that is the first i will do tomorrow.
But so far no suggestions?
Use a cast. auto _cannot_ be different types depending on what you return. It
must always resolve to the same type. So, in this case, either it needs to
resolve
Namespace:
But so far no suggestions?
This seems to work, but solutions that use cast() are sometimes
fragile (and dangerous):
auto foo(bool b) {
final switch (b) {
case false:
return 20.0;
case true:
return cast(typeof(return))10;
}
}
void
On Tuesday, September 11, 2012 23:55:40 bearophile wrote:
Namespace:
But so far no suggestions?
This seems to work, but solutions that use cast() are sometimes
fragile (and dangerous):
auto foo(bool b) {
final switch (b) {
case false:
return 20.0
see no reason to use auto here. If you know
what the return type is supposed to be (e.g. double), then just use double.
Casting where it's unnecessary is just begging for bugs.
Based on Namespace's posts in this thread, I get the impression that what he
wanted was that the return type would
You mean so?
ref Variant get() {
return this._num; // with Variant _num;
}
alias get this;
and then:
int i = zahl.get!int?
No. Then I use my solution as you can see on DPaste. If Variant
works only this way I can also set float to the return type an
cast if I need to int.
And with my
float to the return type an
cast if I need to int.
And with my solution I have in calculation a numeric value and
doesn't have to cast with Variant's get method.
If want the result to always be the same type, then either use the explicit
type or auto (though clearly auto is having some issues
On Tuesday, 11 September 2012 at 21:31:17 UTC, Namespace wrote:
On Tuesday, 11 September 2012 at 21:13:02 UTC, bearophile wrote:
Namespace:
I have this code, but it works not as expected:
http://dpaste.dzfl.pl/6ce5b4dd
I suggest to file a bug:
auto foo(bool b) {
final switch (b
On Wednesday, 15 August 2012 at 01:22:41 UTC, Era Scarecrow wrote:
On Wednesday, 15 August 2012 at 00:37:32 UTC, ReneSac wrote:
And my last question of my first post: I can't use auto for
the out values right? An enhancement proposal like this
would be compatible with D?
I would say
of out value,
because values after cast() apparently aren't lvalues.
And my last question of my first post: I can't use auto for the
out values right? An enhancement proposal like this would be
compatible with D?
Also, the function duplication workaround doesn't works if I
templatize
On Wednesday, 15 August 2012 at 00:37:32 UTC, ReneSac wrote:
And my last question of my first post: I can't use auto for
the out values right? An enhancement proposal like this would
be compatible with D?
I would say No. Maybe if it was a union, but I don't think
so;.It still needs
On 08/14/2012 06:22 PM, Era Scarecrow wrote:
On Wednesday, 15 August 2012 at 00:37:32 UTC, ReneSac wrote:
And my last question of my first post: I can't use auto for the
out values right? An enhancement proposal like this would be
compatible with D?
I would say No. Maybe
On Wednesday, 15 August 2012 at 01:42:11 UTC, Ali Çehreli wrote:
Agreed. The function code must be compiled to use certain
amount of data from the program stack for that particular
parameter. That size of that parameter must be known at compile
time.
The compiler could in theory examine the
);
}
This is not working inside a class. I'm not sure what default
value I should put when I don't know the type entered:
class a (T) {
T dummy = T.init;
bool foo(int a, out T optional = dummy)
{
return true;
}
}
void main () {
auto c = new
)
{
return true;
}
}
void main () {
auto c = new a!uint();
c.foo(5);
}
I get the following error:
Error: need 'this' to access member dummy
I am not a fan of this solution either. To make the code to compile,
define dummy as static:
static T dummy = T.init; // -- this works
There is no compiler bug. You cannot pass immutable/rvalue by reference
to mutable.
On Tuesday, 24 July 2012 at 03:25:55 UTC, ReneSac wrote:
Do I really have to duplicate the function, in order to achieve
this?
In a nutshell, yes. Or else resort to bizarre sorcery such as
may rot the very heart from one's chest (or template ninjitsu,
whatever). But is it really so
Am 24.07.2012 05:25, schrieb ReneSac:
I whish there was:
auto foo() {
return Tuple!(foo, bar, 1, new Custum());
}
void main() {
auto (s1, s2, i, c) = foo();
}
On Tuesday, 24 July 2012 at 03:25:55 UTC, ReneSac wrote:
How I can return multiple values in D, but one of them being
optional?
One of the ways to to it is to return a tuple with your
arguments, where the last item of the tuple is a Nullable of the
optional element:
import std.stdio,
On Tuesday, 24 July 2012 at 08:56:21 UTC, David wrote:
Am 24.07.2012 05:25, schrieb ReneSac:
I whish there was:
auto foo() {
return Tuple!(foo, bar, 1, new Custum());
}
void main() {
auto (s1, s2, i, c) = foo();
}
I think the main blocker to something like that right now
It seems forum.dlang.org hides my first answer, I don't know why:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learnarticle_id=37708
Bye,
bearophile
--
return result, iterations_needed
end
a, stats = foo()
or, if you are only interested in the result:
a = foo() -- the second return is automatically discarded.
Do I really have to duplicate the function, in order to achieve
this?
Also, is there some way to use auto with multiple returns
On 07/23/2012 08:25 PM, ReneSac wrote:
How I can return multiple values in D, but one of them being optional? I
tried the 'out' hack to achieve multiple return values, but it didn't
accepted a default argument: it needed a lvalue in the calling function.
Like in C and C++, functions in D can
.
(1)
auto factorial(int n) {
if (n 2) return 1;
return n * factorial(n-1);
}
The compiler complained about forward declaration of
factorial. If I
change the return type to int, the problem goes away. I can
understand
that with the recursion, it might be impossible for the
compiler
Hello all,
I came across some weird behaviors yesterday and I can't figure
out what it's about.
(1)
auto factorial(int n) {
if (n 2) return 1;
return n * factorial(n-1);
}
The compiler complained about forward declaration of factorial.
If I change the return type to int
On Wednesday, 27 June 2012 at 09:07:57 UTC, Michael wrote:
Hello all,
I came across some weird behaviors yesterday and I can't
figure out what it's about.
(1)
auto factorial(int n) {
if (n 2) return 1;
return n * factorial(n-1);
}
The compiler complained about forward
On 06/27/2012 11:07 AM, Michael wrote:
Hello all,
I came across some weird behaviors yesterday and I can't figure out
what it's about.
(1)
auto factorial(int n) {
if (n 2) return 1;
return n * factorial(n-1);
}
The compiler complained about forward declaration of factorial. If I
On 06/27/2012 01:24 PM, Timon Gehr wrote:
On 06/27/2012 11:07 AM, Michael wrote:
Hello all,
I came across some weird behaviors yesterday and I can't figure out
what it's about.
(1)
auto factorial(int n) {
if (n 2) return 1;
return n * factorial(n-1);
}
The compiler complained
On Saturday, 16 June 2012 at 09:31:35 UTC, Tommi wrote:
Do you consider it to be good or bad style of programming to
use consistently auto as function return type?
One of the pros is that it saves some redundant typing when the
function returns some complex templated type:
auto getValue
On 06/16/2012 11:31 AM, Tommi wrote:
Do you consider it to be good or bad style of programming to use
consistently auto as function return type?
One of the pros is that it saves some redundant typing when the function
returns some complex templated type:
auto getValue()
{
return MyType
Tommi:
Do you consider it to be good or bad style of programming to
use consistently auto as function return type?
In Python programming you don't specify the types of function
arguments and return values, but while this is possible in
Haskell too, it's good practice to write down input
This is valid Scala code:
object Main {
def main(args: Array[String]): Unit = {
val a: List[BigInt] = List(1, BigInt(2))
}
}
Is it possible/meaningful to support/allow D code like this?
import std.bigint;
void main() {
BigInt[] a = [1, BigInt(2)];
}
Bye,
bearophile
On 06/12/2012 12:55 AM, bearophile wrote:
This is valid Scala code:
object Main {
def main(args: Array[String]): Unit = {
val a: List[BigInt] = List(1, BigInt(2))
}
}
Is it possible/meaningful to support/allow D code like this?
import std.bigint;
void main() {
I have been playing around with D as a scripting tool and have
been running into the following issue:
---
import std.algorithm;
struct Delim {
char delim;
this(char d) {
delim = d;
}
}
void main() {
char[] d = ['a', 'b', 'c'];
auto
;
}
}
void main() {
char[] d = ['a', 'b', 'c'];
auto delims = map!Delim(d);
}
/*
Compiling gives me the following error:
/usr/include/d/dmd/phobos/std/algorithm.d(382): Error: constructor
test.Delim.this (char d) is not callable using argument types (dchar)
/usr/include/d/dmd/phobos/std
;
}
}
void main() {
char[] d = ['a', 'b', 'c'];
auto delims = map!Delim(d);
}
/*
Compiling gives me the following error:
/usr/include/d/dmd/phobos/std/algorithm.d(382): Error:
constructor test.Delim.this (char d) is not callable using
argument types (dchar)
/usr/include
Did you know that auto is not auto in the way auto behalfs. it's just a
placeholder so the compiler can determine that a variable follows. but
you can use any other keyword for type interfering, too.
void main()
{
const a = FunctionThatReturnsSomething();
static b = 5.0;
scope c = hey;
}
Just curious:
is there any performance gap using auto instead of int or other
type? For example
int[] ar1 = new int[1000];
auto[] ar2 = new int[1000];
are these equivalent by a perfomance point of view?
Thx
On 11/24/11 10:09 PM, Trass3r wrote:
Well the runtime performance is equal but of course compilation takes
slightly longer since it has to deduce the type first.
Just curious: I would be surprised if there was actually a measurable
difference between the two – did you ever try to measure it?
The type has to be deduced anyway for type checking the
assignment/initialization.
Makes sense. Overseen that.
But I bet you would waste more memory at compile-time if you had to
type a long template instance name instead of using auto. We're
talkin' bytes here!
On Friday, October 21, 2011 16:51 simendsjo wrote:
Is this a temporary restriction?
class C {
invariant() { }
auto f() {
return 1;
}
}
Error: function C.f post conditions are not supported if the return type
is inferred
http://d.puremagic.com/issues/show_bug.cgi?id=5039
On 22.10.2011 02:06, Jonathan M Davis wrote:
On Friday, October 21, 2011 16:51 simendsjo wrote:
Is this a temporary restriction?
class C {
invariant() { }
auto f() {
return 1;
}
}
Error: function C.f post conditions are not supported if the return type
is inferred
http://d.puremagic.com
parents of some class object
until it finds an object with no parent (where parent is null):
import std.stdio;
class Foo
{
Foo parent;
int state;
this (int state) { this.state = state; }
}
void main()
{
auto foo = new Foo(0);
foo.parent = new Foo(1);
foo.parent.parent = new Foo(2);
while (true
that iterates through parents of some class
object
until it finds an object with no parent (where parent is null):
import std.stdio;
class Foo
{
Foo parent;
int state;
this (int state) { this.state = state; }
}
void main()
{
auto foo = new Foo(0);
foo.parent = new Foo(1
semantics for such
a
construct.
//example
//more to the nature of while
while(auto obj = init) { work(obj); }
//1 (your interpretation)
typeof(init) obj;
while(obj = init) { work(obj); }
//2
/*
seems more natural for me because init runs only once (like any other
init and like
for 'while'.
I'm unsure because there are two somewhat natural semantics for
such
a
construct.
//example
//more to the nature of while
while(auto obj = init) { work(obj); }
//1 (your interpretation)
typeof(init) obj;
while(obj = init) { work(obj); }
//2
unsure because there are two somewhat natural semantics for
such a
construct.
//example
//more to the nature of while
while(auto obj = init) { work(obj); }
//1 (your interpretation)
typeof(init) obj;
while(obj = init) { work(obj); }
//2
/*
seems more natural for me because
that part is only executed once.
The while loop just doesn't fit the model. Let's ditch the while loop.
Not relevant, you are not declaring a variable in your example. The
benefit of using the auto x = y is that you can move the declaration of
the variable, which is used only during the loop
. Our two examples are equivalent in what they are saying on a
conceptual level. Whether the condition contains a declaration or an
increment operation does not matter.
The
benefit of using the auto x = y is that you can move the declaration of
the variable, which is used only during the loop
.
The
benefit of using the auto x = y is that you can move the declaration
of
the variable, which is used only during the loop, into the loop
statement.
The benefit of using the auto x = y is that you can declare a new
variable inside the condition, plus useful scoping.
I think you just
.
The
benefit of using the auto x = y is that you can move the declaration of
the variable, which is used only during the loop, into the loop
statement.
The benefit of using the auto x = y is that you can declare a new
variable inside the condition, plus useful scoping.
I think you just said the same
a
variable in either loop. :)
If 'while' gets this enhancement, 'for' could be written as the following:
for (int i = 0; auto c = condition(); ++i) {
// Yes, we know that c doesn't evaluate to 'false', but
// we can use c here when it evaluates to 'true'.
// e.g. if it's a pointer
there is no discrepancy: the condition clauses cannot define a
variable in either loop. :)
There is a little discrepancy because 'if' condition clauses can. ;)
If 'while' gets this enhancement, 'for' could be written as the following:
for (int i = 0; auto c = condition(); ++i) {
// Yes, we know that c
Here's some code that iterates through parents of some class object
until it finds an object with no parent (where parent is null):
import std.stdio;
class Foo
{
Foo parent;
int state;
this (int state) { this.state = state; }
}
void main()
{
auto foo = new Foo(0
P.S. I'm aware I'm loosing the reference to the first foo object but
this is just demonstration code.
; }
}
void main()
{
auto foo = new Foo(0);
foo.parent= new Foo(1);
foo.parent.parent = new Foo(2);
while (true)
{
if (auto par = foo.parent)
{
writeln(par.state);
foo = par;
}
else
On 8/24/11, Timon Gehr timon.g...@gmx.ch wrote:
it is usually faster
in debug mode
Huh.. How come?
On 08/24/2011 09:21 PM, Andrej Mitrovic wrote:
On 8/24/11, Timon Gehrtimon.g...@gmx.ch wrote:
it is usually faster
in debug mode
Huh.. How come?
Well, not notably faster, but many compilers will emit something in the
lines of
mov eax, 1
test eax
jnz beginning_of_loop
if no optimizer is
On Wednesday, August 24, 2011 21:29:23 Timon Gehr wrote:
On 08/24/2011 09:21 PM, Andrej Mitrovic wrote:
On 8/24/11, Timon Gehrtimon.g...@gmx.ch wrote:
it is usually faster
in debug mode
Huh.. How come?
Well, not notably faster, but many compilers will emit something in the
lines
On 08/24/2011 09:36 PM, Jonathan M Davis wrote:
On Wednesday, August 24, 2011 21:29:23 Timon Gehr wrote:
On 08/24/2011 09:21 PM, Andrej Mitrovic wrote:
On 8/24/11, Timon Gehrtimon.g...@gmx.ch wrote:
it is usually faster
in debug mode
Huh.. How come?
Well, not notably faster, but many
Req'd: http://d.puremagic.com/issues/show_bug.cgi?id=6550
) { this.state = state; }
}
void main()
{
auto foo = new Foo(0);
foo.parent = new Foo(1);
foo.parent.parent = new Foo(2);
while (true)
{
if (auto par = foo.parent)
{
writeln(par.state);
foo = par;
}
else
{
break;
}
}
}
(syntax-highlighted: http://codepad.org/8yHRmICh)
But I was hoping I could
parent;
int state;
this (int state) { this.state = state; }
}
void main()
{
auto foo = new Foo(0);
foo.parent = new Foo(1);
foo.parent.parent = new Foo(2);
while (true)
{
if (auto par = foo.parent)
{
writeln(par.state);
foo = par;
}
else
{
break;
}
}
}
(syntax-highlighted: http://codepad.org
Andrej Mitrovic:
I don't think the compiler can figure that one out unless tuples
become a standard language feature, not a library one. But maybe I'm
wrong.
Turning tuples into a a _partial_ language feature will be a good thing [TM]
for D. Tuples are useful in many situations, and they are
On 17/05/2011 04:40, Andrej Mitrovic wrote:
auto foo()
{
if (1)
{
return [0, 0];
}
else
{
size_t one;
size_t two;
return [one, two];
}
}
void main(){ }
Error: mismatched function return type inference of
uint[] and int
Bug is in bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=6022
I'm not a compiler writer though, sorry. :)
auto foo()
{
if (1)
{
return [0, 0];
}
else
{
size_t one;
size_t two;
return [one, two];
}
}
void main(){ }
Error: mismatched function return type inference of
uint[] and int[]
Surely the compiler can figure out a common type
On 2011-05-16 20:40, Andrej Mitrovic wrote:
auto foo()
{
if (1)
{
return [0, 0];
}
else
{
size_t one;
size_t two;
return [one, two];
}
}
void main(){ }
Error: mismatched function return type inference of
uint[] and int
Yeah it's low priority, but nice to have.
Note that there's a similar issue with tuples. However since tuples
are a library type and not first-class citizens (when it comes to
return types that is), the compiler probably won't be able to figure
out a common type.
What I mean is this:
auto foo
out a common type.
What I mean is this:
auto foo()
{
if (1)
{
tuple(0, 0);
}
else
{
size_t one;
size_t two;
tuple(one, two);
}
}
I don't think the compiler can figure that one out unless tuples
become a standard language feature
import std.traits;
void main()
{
const wchar* t;
unqual(t);
}
auto ref unqual(T)(ref T value)
{
return cast(Unqual!T)value;
}
I've attempted to create myself an unqual function which could for example do a
cast from const char* to char*. The above won't work though:
test.d(14
import std.traits;
void main()
{
const wchar* t;
unqual(t);
}
auto ref unqual(T)(ref T value)
{
return cast(Unqual!T)value;
}
I've attempted to create myself an unqual function which could for example
do a cast from const char* to char*. The above won't work though
Oh I've just realized I was being a little silly here. I don't need
ref for pointers. Essentially I was looking to make this:
auto ref unqual(T)(ref T value)
{
return cast(Unqual!T)value;
}
do this:
char* unqual(const char* value)
{
return cast(char*)value;
}
Except to make it work
is there any different b/w:
auto arr = new int[10];
and
int[10] arr;
?
%u wrote:
is there any different b/w:
auto arr = new int[10];
arr is dynamic array of int with ten elements
and
int[10] arr;
?
arr is static array of int with ten elements
On Fri, 07 Jan 2011 16:30:24 -0800, Jonathan M Davis wrote:
On Friday, January 07, 2011 13:32:42 Ellery Newcomer wrote:
auto a = 1, b = null;
int a = 1, *b = null;
[...]
[...]
However, I'm vere suprised that the first one succeeds. I think that it
should be reported as a bug. All
On Monday 10 January 2011 01:59:34 Lars T. Kyllingstad wrote:
On Fri, 07 Jan 2011 16:30:24 -0800, Jonathan M Davis wrote:
On Friday, January 07, 2011 13:32:42 Ellery Newcomer wrote:
auto a = 1, b = null;
int a = 1, *b = null;
[...]
[...]
However, I'm vere suprised
Ellery Newcomer:
int a = 1, *b = null;
Walter has disallowed code like this in D because in C it is a well known
source of bugs (so much that C style guides strongly suggest to declare only
each variable in a distinct statement and line of code).
auto a = 1, b = null;
I have discussed
auto a = 1, b = null;
int a = 1, *b = null;
The first is accepted by dmd, and it should result in typeof(a) == int
and typeof(b) == void*. It is somewhat contradictory to the error
message resulting from the second:
multiple declarations must have the same type, not int and int*
I am
Ellery Newcomer wrote:
auto a = 1, b = null;
int a = 1, *b = null;
The first is accepted by dmd, and it should result in typeof(a) == int
and typeof(b) == void*. It is somewhat contradictory to the error
message resulting from the second:
multiple declarations must have the same type
On Friday, January 07, 2011 13:32:42 Ellery Newcomer wrote:
auto a = 1, b = null;
int a = 1, *b = null;
The first is accepted by dmd, and it should result in typeof(a) == int
and typeof(b) == void*. It is somewhat contradictory to the error
message resulting from the second:
multiple
I'm sure this has come up before, but I want to store something like an
std.array appender in a class. All of the examples use auto for the type but
you can't put that in a class definition, so what do you put?
Example:
class packet{...}
class A {
packet [] packetlist;
appender!(packet
On Friday, July 02, 2010 09:46:37 Rob Adelberg wrote:
I'm sure this has come up before, but I want to store something like an
std.array appender in a class. All of the examples use auto for the type
but you can't put that in a class definition, so what do you put?
Example:
class packet
On Sun, 27 Jun 2010 17:17:25 +0200, Philippe Sigaud
philippe.sig...@gmail.com wrote:
Is it defined somewhere that auto functions are not authorized inside
main?
void main()
{
auto fun(string s) { return s;} // this does not compile
}
error:
main.d|6|found 's' when expecting
Hello Rory,
On Sun, 27 Jun 2010 17:17:25 +0200, Philippe Sigaud
philippe.sig...@gmail.com wrote:
void main()
{
auto fun(string s) { return s;} // this does not compile
}
Hope this isn't a stupid question, but how would you access this
function
if it did work?
Would it be fun(asdf
On Mon, 28 Jun 2010 16:07:43 +0200, Philippe Sigaud philippe.sig...@gmail.com wrote:On Mon, Jun 28, 2010 at 15:40, Rory McGuire rmcgu...@neonova.co.za wrote:
void main()
{
auto fun(string s) { return s;} // this does not compile
}
Hope this isn't a stupid question, but how would you
On Mon, 28 Jun 2010 16:01:46 +0200, BCS n...@anon.com wrote:
Hello Rory,
On Sun, 27 Jun 2010 17:17:25 +0200, Philippe Sigaud
philippe.sig...@gmail.com wrote:
void main()
{
auto fun(string s) { return s;} // this does not compile
}
Hope this isn't a stupid question, but how would you
Is it defined somewhere that auto functions are not authorized inside main?
void main()
{
auto fun(string s) { return s;} // this does not compile
}
error:
main.d|6|found 's' when expecting ')'|
main.d|6|semicolon expected, not ')'|
main.d|6|found ')' instead of statement|
main.d|7
Philippe Sigaud:
I couldn't find a bugzilla entry for this and I cannot believe no one ever
tried to put an auto fun inside main!
Maybe auto funcs are seen as instantiated templates, and templates can't be
defined inside functions. Anyway, I think you can file this as enhancement
request
Do you have something in the Error Log (Window - Show View - Error
Log)? How is your project configured? Do you have phobos or Tango in the
include path?
My Eclipse doesn't have a thing called Error Log. I can't see more than
'D Build Path' to configure.
I've been testing with Tangos
Joel Christensen wrote:
I've got one project working ok, but not another. Things like working at
the start of the main function but not at the end, and not in other
functions.
Hi Joel,
Do you have something in the Error Log (Window - Show View - Error
Log)? How is your project configured?
601 - 695 of 695 matches
Mail list logo
