On Wednesday, 30 July 2025 at 20:03:37 UTC, 0xEAB wrote:
On Wednesday, 30 July 2025 at 19:45:20 UTC, Andy Valencia wrote:
but I'd like to understand what's up before just changing my
code to assume 0 is a success value?
AFAICT your code is wrong.
The parameters of `fread()` are `ptr`, `size`,
On 7/30/25 12:45 PM, Andy Valencia wrote:
> Scratching my head here. fread()
I haven't used anything other than rawRead() for that purpose. rawRead()
returns a slice of what it's just read:
import std.algorithm;
import std.exception;
import std.file;
import std.format;
import std.stdio;
void
On Wednesday, 30 July 2025 at 19:45:20 UTC, Andy Valencia wrote:
but I'd like to understand what's up before just changing my
code to assume 0 is a success value?
AFAICT your code is wrong.
The parameters of `fread()` are `ptr`, `size`, `n`, `stream`.
Your code is attempting to read `1` unit wi
On Wednesday, 30 July 2025 at 19:45:20 UTC, Andy Valencia wrote:
Scratching my head here. fread() really appears to be the
standard C idea of an fread(), so it returns a count. Instead,
it returns 0. The buf[] does indeed have the expected content,
but I'd like to understand what's up before
Scratching my head here. fread() really appears to be the
standard C idea of an fread(), so it returns a count. Instead,
it returns 0. The buf[] does indeed have the expected content,
but I'd like to understand what's up before just changing my code
to assume 0 is a success value?
(Linux,
On Tuesday, 7 September 2021 at 05:00:50 UTC, Chris Piker wrote:
On Tuesday, 7 September 2021 at 04:40:25 UTC, jfondren wrote:
typeof(parseXML!simpleXML("")) xml;
Hey, I like this trick!
I was wondering what to use for the const(char)[] variable in
the typeof statement. It's blindingly
On Tuesday, 7 September 2021 at 08:27:33 UTC, JN wrote:
On Tuesday, 7 September 2021 at 04:13:08 UTC, Chris Piker wrote:
Like almost all new users to D I'm tripping over how to save
and pass around variables since nothing has an understandable
type anymore and you can't use "auto" for *class me
On Tuesday, 7 September 2021 at 04:13:08 UTC, Chris Piker wrote:
Like almost all new users to D I'm tripping over how to save
and pass around variables since nothing has an understandable
type anymore and you can't use "auto" for *class member*
storage types.
I struggle with this often. Templ
On Tuesday, 7 September 2021 at 04:40:25 UTC, jfondren wrote:
typeof(parseXML!simpleXML("")) xml;
Hey, I like this trick!
I was wondering what to use for the const(char)[] variable in the
typeof statement. It's blindingly obvious in retrospect.
Wouldn't work so well if there wasn't a
On Tuesday, 7 September 2021 at 04:13:08 UTC, Chris Piker wrote:
Any ideas on how to get the return type of `parseXML` below:
```
import dxml.parser;
const(char)[] _mmfile;
//_mmfile initialization
TYPE??? _entityRng = parseXML!(simpleXML)(_mmfile);
```
Though it's ususally bad form to respond
On Tuesday, 7 September 2021 at 04:13:08 UTC, Chris Piker wrote:
Any ideas on how to get the return type of `parseXML` below:
```
import dxml.parser;
const(char)[] _mmfile;
//_mmfile initialization
TYPE??? _entityRng = parseXML!(simpleXML)(_mmfile);
```
*before* calling parseXML, so that it can
Hi D
I'm using the **dxml** library since I like it's "pull here for
more data" mentality. I've come across the need to save an
entity range created by the `parseXML` function as a class member
so that I can tuck it away and pull more data as needed.
Like almost all new users to D I'm trip
On Saturday, 2 February 2019 at 09:58:25 UTC, XavierAP wrote:
I've heard here and there that D guarantees RVO, or is even
specified to do so...
Is it spelled out in the language specification or elsewhere? I
haven't found it.
The D spec is often not the right place to look for the
specifica
I've heard here and there that D guarantees RVO, or is even
specified to do so...
Is it spelled out in the language specification or elsewhere? I
haven't found it.
Do you know the exact requirements for RVO or NRVO to be possible
in theory, and to be guaranteed in practice in D? Does it depe
On Saturday, 17 February 2018 at 13:47:28 UTC, meppl wrote:
On Saturday, 17 February 2018 at 07:58:40 UTC, ANtlord wrote:
...
...
sadly I have no good idea how to name the title of that issue :/
I looked at it again and came up with a title name:
https://issues.dlang.org/show_bug.cgi?id=184
On Saturday, 17 February 2018 at 07:58:40 UTC, ANtlord wrote:
Hello!
Yesterday I found an interesting issue for myself while I was
implementing unique pointer for my project in BetterC. When I
was trying to return new instance from a `move` method I got
calling of destructor the instance. When
Hello!
Yesterday I found an interesting issue for myself while I was
implementing unique pointer for my project in BetterC. When I was
trying to return new instance from a `move` method I got calling
of destructor the instance. When the instance is out of scope the
calling is happens again. I
On Wednesday, 15 November 2017 at 11:20:24 UTC, Biotronic wrote:
Thanks Biotronic! I found this on the html documentation for
templates: "The body of the TemplateDeclaration must be
syntactically correct even if never instantiated. Semantic
analysis is not done until instantiated", and that is
On Wednesday, 15 November 2017 at 08:43:01 UTC, Tony wrote:
Error: function test_warnings.MyClass.SomeMethod has no return
statement, but is expected to return a value of type int
but if I make it a template class:
class MyClass(T) {
there is no compile error. I don't know why the error isn't
On Wednesday, 15 November 2017 at 08:43:01 UTC, Tony wrote:
This code:
class MyClass {
public:
int SomeMethod ()
{
}
}
void main()
{
}
gets a compile error:
Error: function test_warnings.MyClass.SomeMethod has no return
statement, but is expected to return a value of type int
b
This code:
class MyClass {
public:
int SomeMethod ()
{
}
}
void main()
{
}
gets a compile error:
Error: function test_warnings.MyClass.SomeMethod has no return
statement, but is expected to return a value of type int
but if I make it a template class:
class MyClass(T) {
there
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen wrote:
The error is: "cannot take address of ref return of this.foo()
in @safe function bar".
Maybe a bugfix in safety system? Should it go through deprecation
process?
On Monday, 20 February 2017 at 21:05:17 UTC, Jack Stouffer wrote:
On Monday, 20 February 2017 at 20:54:31 UTC, Jack Stouffer
wrote:
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen
wrote:
...
Yeah, this is another regression caused by DIP1000.
Christ.
For the record, the current
On Monday, 20 February 2017 at 20:54:31 UTC, Jack Stouffer wrote:
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen
wrote:
...
Yeah, this is another regression caused by DIP1000.
Christ.
For the record, the current list of regressions caused by DIP1000
https://issues.dlang.org/sho
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen wrote:
...
Yeah, this is another regression caused by DIP1000.
Christ.
This code compiles with 2.071, but not with 2.072 nor 2.073:
```
struct S {
int i;
auto ref foo() @safe {
return i;
}
auto bar() @safe {
return &foo(); // <-- Error
}
}
void main() {
auto s = S();
s.bar(
On Wednesday, 21 September 2016 at 12:39:57 UTC, Johan Engelen
wrote:
It should really be mentioned in the documentation of
toHexString, with an actual example instead of a unittest.
Do you use my dpldocs.info? I add such notes there from time to
time:
http://dpldocs.info/experimental-docs/s
On Wednesday, 21 September 2016 at 13:06:08 UTC, Adam D. Ruppe
wrote:
the variable you are assigning the result to never does
anything with regard to overloads or template args.
Gotcha, thanks.
On Wednesday, 21 September 2016 at 12:29:54 UTC, Johan Engelen
wrote:
Wouldn't something like this be possible?
`T toHexString(string toHexString(Order order =
Order.increasing, LetterCase letterCase = LetterCase.upper,
T)(.) if (T == string)`
I'm not sure what that's supposed to be.
On Wednesday, 21 September 2016 at 12:20:14 UTC, Adam D. Ruppe
wrote:
This is a pretty common pitfall (and IMO one of the most
egregious design flaws in the language), I see it all the time.
I write very little D code, so I guess it had to happen at some
point then. Man, this is really bad :
On Wednesday, 21 September 2016 at 12:20:14 UTC, Adam D. Ruppe
wrote:
It is neither, the compiler chose the right overload (remember,
overloads are chosen based on the arguments alone, the type you
specify for the variable holding the return value isn't a
consideration there) an
It is neither, the compiler chose the right overload (remember,
overloads are chosen based on the arguments alone, the type you
specify for the variable holding the return value isn't a
consideration there) and the implementation of each overload is
correct.
But the horribly wrong imp
What's the bug in the following code:
```d
import std.digest.md;
import std.stdio;
pragma(inline, false) // just in case
string getHash()
{
ubyte[16] hash = [1,2,3,4,5,6,6,78,8,8,7,7,6,3,2,3];
string a = toHexString(hash);
return a;
}
pragma(inline, false) // just in case
void destr
Thank you both for the very good insights. Community wise +1 :)
On Wednesday, 13 July 2016 at 11:11:51 UTC, celavek wrote:
I misunderstood the doc and I got a bit confused by the range -
in C++ I would have incremented the iterators but here I did
not know what to do exactly as I could not match the 2
different concepts in functionality.
it mostly maps to
eturn an empty
tuple rather than a tuple of two empty ranges. Being more
specific about the return value is only a few extra words that
I wouldn't judge as being "too wordy".
probably you are right. it is somewhat hard to judge when you
know the concept "by your heart"
On Wednesday, 13 July 2016 at 11:11:51 UTC, celavek wrote:
Thank you for the example.
I misunderstood the doc and I got a bit confused by the range -
in C++ I would have incremented the iterators but here I did
not know what to do exactly as I could not match the 2
different concepts in funct
has achieved
a certain level of comfort and familiarity with ranges and the
range-based functions in Phobos. This particular function could
just as easily be inferred to return an empty tuple rather than a
tuple of two empty ranges. Being more specific about the return
value is only a few extra words that I wouldn't judge as being
"too wordy".
Thank you for the example.
I misunderstood the doc and I got a bit confused by the range -
in C++ I would have incremented the iterators but here I did not
know what to do exactly as I could not match the 2 different
concepts in functionality.
On Wednesday, 13 July 2016 at 11:06:56 UTC, celavek wrote:
On Wednesday, 13 July 2016 at 10:41:44 UTC, ketmar wrote:
I understand your point but it should not be a matter of
guessing.
It should be explicitly stated by the documentation.
then people will start to complain that documentation is
On Wednesday, 13 July 2016 at 10:41:44 UTC, ketmar wrote:
let's read the doc again: "Returns a tuple with the reduced
ranges that start with the two mismatched values." simple logic
allows us to guess that it should return tuple with two empty
ranges. and it really does.
I understand your
inite loop. What does mismatch return when
it cannot
actually find a mismatch? Is the return value immutable?
I do not get any warnings from the compiler(dmd).
The return value is described as:
"a tuple with the reduced ranges that start with the two
mismatched values"
This means
ic
allows us to guess that it should return tuple with two empty
ranges. and it really does.
Is the return value immutable?
as with most other std.algo functions, the returned range has
same properties as source range.
On Wednesday, 13 July 2016 at 09:59:30 UTC, celavek wrote:
As a side note the documentation of the standard library is not
digestible to say the least - there is missing info(e.g. what
does mismatch return
if no mismatch found) and lacks user-friendliness and details.
Whenever you find areas
lly find a mismatch? Is the return value immutable?
I do not get any warnings from the compiler(dmd).
As a side note the documentation of the standard library is not
digestible to say the least - there is missing info(e.g. what
does mismatch return
if no mismatch found) and lacks user-friendliness and details.
Oops found it my self.
I had to use
auto x = foo();
I tried your code as this and it doesn't work.
#!/usr/bin/rdmd -O
import std.stdio;
struct S {
int a;
@disable this(this);
};
S foo() {
S v;
v.a = 1;
writeln(&v);
return v;
}
void main()
{
S x;
x = foo();
writeln(&x);
}
I even tried with dmd -O without su
On Sunday, 27 September 2015 at 13:55:02 UTC, chmike wrote:
Can someone please explain me why this doesn't work as I would
expect RVO to work ?
I'm not an expert on the subject so this may contain some
inaccuracies, but the gist of it is:
As the name implies, NRVO is an optimization and ther
doesn't do RVO as I expected it would do
it.
Here is the D code. It is very similar to the C code I tested
with gcc and clang :
---
#!/usr/bin/rdmd -O
import std.stdio;
struct S { int a, b; };
S foo(S* p) {
S v = {1, 2};
writeln("foo: return value optimization: ", p == &a
On 06/18/2015 05:25 PM, Yuxuan Shui wrote:
> What problem can moving a scoped cause when there's
> no reference to its inner class?
I am curious as well. Could it be related to the object's 'monitor'?
Perhaps some other code may have a reference to monitor? And that
reference does not constitu
On Friday, 19 June 2015 at 00:00:50 UTC, Ali Çehreli wrote:
On 06/18/2015 04:53 PM, Yuxuan Shui wrote:
> On Thursday, 11 June 2015 at 21:38:59 UTC, Ali Çehreli wrote:
>> About returning scoped!C, I think it works:
> I just find out that the document of scoped says that "It's
Thanks for fixing
On 06/18/2015 04:53 PM, Yuxuan Shui wrote:
> On Thursday, 11 June 2015 at 21:38:59 UTC, Ali Çehreli wrote:
>> About returning scoped!C, I think it works:
> I just find out that the document of scoped says that "It's
Thanks for fixing the typo there. (The documentations has lower case:
"it's".
On Thursday, 11 June 2015 at 21:38:59 UTC, Ali Çehreli wrote:
On 06/11/2015 12:51 PM, Yuxuan Shui wrote:
> On Thursday, 11 June 2015 at 19:23:49 UTC, Ali Çehreli wrote:
>> [...]
>
> Can you explain more about why the destructor is not called
when
> returning a struct?
Are you asking in general
On Thursday, 11 June 2015 at 19:23:49 UTC, Ali Çehreli wrote:
On 06/11/2015 11:43 AM, Yuxuan Shui wrote:
On Thursday, 11 June 2015 at 17:34:56 UTC, Steven
Schveighoffer wrote:
On 6/11/15 1:28 PM, Yuxuan Shui wrote:
On Thursday, 11 June 2015 at 09:11:47 UTC, Daniel Kozák
wrote:
On Thu, 11 Jun
On 06/11/2015 11:43 AM, Yuxuan Shui wrote:
On Thursday, 11 June 2015 at 17:34:56 UTC, Steven Schveighoffer wrote:
On 6/11/15 1:28 PM, Yuxuan Shui wrote:
On Thursday, 11 June 2015 at 09:11:47 UTC, Daniel Kozák wrote:
On Thu, 11 Jun 2015 09:01:04 +
Yuxuan Shui via Digitalmars-d-learn
wrote
On Thursday, 11 June 2015 at 17:34:56 UTC, Steven Schveighoffer
wrote:
On 6/11/15 1:28 PM, Yuxuan Shui wrote:
On Thursday, 11 June 2015 at 09:11:47 UTC, Daniel Kozák wrote:
On Thu, 11 Jun 2015 09:01:04 +
Yuxuan Shui via Digitalmars-d-learn
wrote:
A x = scoped!A(10);
use auto x = s
On 6/11/15 1:28 PM, Yuxuan Shui wrote:
On Thursday, 11 June 2015 at 09:11:47 UTC, Daniel Kozák wrote:
On Thu, 11 Jun 2015 09:01:04 +
Yuxuan Shui via Digitalmars-d-learn
wrote:
A x = scoped!A(10);
use auto x = scoped!A(10);
Thanks!
Curious question, why doesn't compiler reject thi
On Thursday, 11 June 2015 at 09:11:47 UTC, Daniel Kozák wrote:
On Thu, 11 Jun 2015 09:01:04 +
Yuxuan Shui via Digitalmars-d-learn
wrote:
A x = scoped!A(10);
use auto x = scoped!A(10);
Thanks!
Curious question, why doesn't compiler reject this code?
On Thu, 11 Jun 2015 09:01:04 +
Yuxuan Shui via Digitalmars-d-learn
wrote:
> A x = scoped!A(10);
use auto x = scoped!A(10);
On Thursday, 11 June 2015 at 08:48:22 UTC, Yuxuan Shui wrote:
Is there a way to encapsulate return value into scoped?
Say I have a function that returns a new object:
X new_x(T t...) {
//Super complex input processing
return new X(something);
}
And I want to encapsulate the result
Is there a way to encapsulate return value into scoped?
Say I have a function that returns a new object:
X new_x(T t...) {
//Super complex input processing
return new X(something);
}
And I want to encapsulate the result using scoped, is that
possible? Can I just do:
return scoped
On Saturday, 16 May 2015 at 10:47:36 UTC, Jakob Ovrum wrote:
Nice! Should I make a PR?
I think that would be very welcome.
https://github.com/D-Programming-Language/phobos/pull/3288
On Saturday, 16 May 2015 at 10:28:11 UTC, Per Nordlöw wrote:
Nice! Should I make a PR?
I think that would be very welcome.
On Saturday, 16 May 2015 at 09:56:22 UTC, Jakob Ovrum wrote:
It can be implemented in a backwards-compatible way as a
subtype of a Tuple.
struct FindSplit(R)
{
Tuple!(R, "pre", R, "separator", R, "post") asTuple;
bool opCast(T : bool)()
{
return !asTuple.separator.empty;
On Saturday, 16 May 2015 at 09:36:30 UTC, Per Nordlöw wrote:
After having written a lot of text pattern matching functions
using Phobos' findSplit, findSplitBefore, findSplitAfter, and
some more I've written myself I've come to the conclusion that
I would like to enhance these functions to inst
After having written a lot of text pattern matching functions
using Phobos' findSplit, findSplitBefore, findSplitAfter, and
some more I've written myself I've come to the conclusion that I
would like to enhance these functions to instead return a struct
instead of tuples. This struct would typi
On Thursday, 24 July 2014 at 17:43:36 UTC, JR wrote:
Is there a big reason why Appender.put doesn't return &this?
http://dpaste.dzfl.pl/bb840e3e349e
It would allow for convenient chaining. :<
AFAIK, no reason no. That said, it wouldn't be useable in generic
code.
Offtop
It's better to return "this" and have return type "ref auto" i
think.
Is there a big reason why Appender.put doesn't return &this?
http://dpaste.dzfl.pl/bb840e3e349e
It would allow for convenient chaining. :<
On Friday, 29 November 2013 at 09:05:50 UTC, Oleg B wrote:
[code]
import std.stdio;
struct A { int val; }
A a;
class X { const ref A func() { return a; } }
void main()
{
auto x = new X;
x.func().val = 5;
writeln( a );
}
[/code]
in this case 'const' mean 'const method' and variabl
[code]
import std.stdio;
struct A { int val; }
A a;
class X { const ref A func() { return a; } }
void main()
{
auto x = new X;
x.func().val = 5;
writeln( a );
}
[/code]
in this case 'const' mean 'const method' and variable 'a' changed.
if write
[code]
class X { const(ref A) func(
bug submitted:
http://d.puremagic.com/issues/show_bug.cgi?id=9969
Thanks for reporting.
By the way, I was compiling for Windows and had only compile time
errors.
On Saturday, 20 April 2013 at 13:37:55 UTC, John Colvin wrote:
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
return dynArr;
}
}
void main()
{
alias
On Saturday, 20 April 2013 at 13:37:55 UTC, John Colvin wrote:
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
return dynArr;
}
}
void main()
{
alias
Made available on dpaste:
http://dpaste.dzfl.pl/7b5c36f8
On dpaste, the struct with an int didn't compile. (Same error
message)
It turns out that
Template!(2, Sint).statArr()[0].writeln();
compiles with
$ dmd test.d -m64
but not with
$ dmd test.d
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
return dynArr;
}
}
void main()
{
alias statArr9 = Template!(9, int).statArr;
alias statArr3
On 12/11/12 22:05, monarch_dodra wrote:
> On Tuesday, 11 December 2012 at 21:00:11 UTC, Timon Gehr wrote:
>> On 12/11/2012 05:58 PM, monarch_dodra wrote:
>>> On Tuesday, 11 December 2012 at 16:45:54 UTC, cal wrote:
On Tuesday, 11 December 2012 at 15:38:38 UTC, monarch_dodra wrote:
> On Tue
On Tuesday, 11 December 2012 at 21:00:11 UTC, Timon Gehr wrote:
On 12/11/2012 05:58 PM, monarch_dodra wrote:
On Tuesday, 11 December 2012 at 16:45:54 UTC, cal wrote:
On Tuesday, 11 December 2012 at 15:38:38 UTC, monarch_dodra
wrote:
On Tuesday, 11 December 2012 at 14:57:27 UTC, monarch_dodra
w
On 12/11/2012 05:58 PM, monarch_dodra wrote:
On Tuesday, 11 December 2012 at 16:45:54 UTC, cal wrote:
On Tuesday, 11 December 2012 at 15:38:38 UTC, monarch_dodra wrote:
On Tuesday, 11 December 2012 at 14:57:27 UTC, monarch_dodra wrote:
:/
I got it to work with a cast, which removes the ambig
On Tuesday, 11 December 2012 at 16:45:54 UTC, cal wrote:
On Tuesday, 11 December 2012 at 15:38:38 UTC, monarch_dodra
wrote:
On Tuesday, 11 December 2012 at 14:57:27 UTC, monarch_dodra
wrote:
:/
I got it to work with a cast, which removes the ambiguity:
auto p = &cast(int)s.front;
But it fee
On Tuesday, 11 December 2012 at 15:38:38 UTC, monarch_dodra wrote:
On Tuesday, 11 December 2012 at 14:57:27 UTC, monarch_dodra
wrote:
:/
I got it to work with a cast, which removes the ambiguity:
auto p = &cast(int)s.front;
But it feels hackish. Any other way?
auto p = &(s.front());
Not s
On Tuesday, 11 December 2012 at 14:57:27 UTC, monarch_dodra wrote:
:/
I got it to work with a cast, which removes the ambiguity:
auto p = &cast(int)s.front;
But it feels hackish. Any other way?
I feel incredibly stupid asking this one, but how does one
extract the address of return value of a member function that
returns by ref?
Case in point:
//
struct S
{
int i;
ref front() @property
{
return i;
}
}
void foo(int*){}
void main()
{
auto s = S
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
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 e
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 if
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 t
Thanks, this indeed works. One "obvious" (when your program
starts to behave weirdly...) down side of this solution: it needs
a different dummy for each optional out value of a function, or
else multiple variables will be modifying the same dummy.
And, of course, a different dummy for each typ
There is no compiler bug. You cannot pass immutable/rvalue by reference
to mutable.
On 08/11/2012 03:48 PM, ReneSac wrote:
> On Tuesday, 24 July 2012 at 05:30:49 UTC, Ali Çehreli wrote:
>> - Use an out parameter, which can have a default lvalue:
>>
>> int g_default_param;
>>
>> void foo(ref int i = g_default_param)
>> {
>> if (&i == &g_param) {
>> // The caller is not interested
On Tuesday, 24 July 2012 at 05:30:49 UTC, Ali Çehreli wrote:
The options that I can think of:
- Return a struct (or a class) where one of the members is not
filled-in
- Similarly, return a tuple
This is awkward, and doesn't look good for performance.
- Use an out parameter, which can hav
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.learn&article_id=37708
Bye,
bearophile
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 is the
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, std.t
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:
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 bad?
ctions in D can also have a single return value.
The most common workaround in C and C++ has been an out parameter
(pointer in C and pointer or reference in C++).
The options that I can think of:
- Return a struct (or a class) where one of the members is not filled-in
- Similarly, return a tupl
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.
In Lua, for example, one can do:
function foo(input)
-- calculations --
1 - 100 of 113 matches
Mail list logo
