On Saturday, 28 March 2020 at 06:56:14 UTC, Bruce Carneal wrote:
On Saturday, 28 March 2020 at 05:21:14 UTC, Crayo List wrote:
On Monday, 23 March 2020 at 18:52:16 UTC, Bruce Carneal wrote:
[snip]
(on the downside you have to guard against compiler code-gen
performance regressions)
auto
On Saturday, 28 March 2020 at 05:21:14 UTC, Crayo List wrote:
On Monday, 23 March 2020 at 18:52:16 UTC, Bruce Carneal wrote:
[snip]
(on the downside you have to guard against compiler code-gen
performance regressions)
auto vectorization is bad because you never know if your code
will get
On Monday, 23 March 2020 at 18:52:16 UTC, Bruce Carneal wrote:
When speeds are equivalent, or very close, I usually prefer
auto vectorized code to explicit SIMD/__vector code as it's
easier to read. (on the downside you have to guard against
compiler code-gen performance regressions)
One
When speeds are equivalent, or very close, I usually prefer auto
vectorized code to explicit SIMD/__vector code as it's easier to
read. (on the downside you have to guard against compiler
code-gen performance regressions)
One oddity I've noticed is that I sometimes need to use
pragma(inline
On Sunday, 23 February 2020 at 18:40:03 UTC, Adam D. Ruppe wrote:
The error I currently get when clicking the documentation link
https://phobos-next.dpldocs.info/ is
try it now.
I've been tweaking the time out and retry numbers lately so it
is less likely to do this but still sometimes does
On Sunday, 23 February 2020 at 18:20:19 UTC, Per Nordlöw wrote:
The error I currently get when clicking the documentation link
https://phobos-next.dpldocs.info/ is
try it now.
I've been tweaking the time out and retry numbers lately so it is
less likely to do this but still sometimes does
On Sunday, 23 February 2020 at 18:18:25 UTC, Per Nordlöw wrote:
On Sunday, 23 February 2020 at 17:18:48 UTC, Andre Pany wrote:
If your Dub package is registered on code.dlang.org, this is
automatically provided.
Example: http://code.dlang.org/packages/arsd-official
Click on the documentation
On Sunday, 23 February 2020 at 17:18:48 UTC, Andre Pany wrote:
If your Dub package is registered on code.dlang.org, this is
automatically provided.
Example: http://code.dlang.org/packages/arsd-official
Click on the documentation link.
Beside that you can use e.g. Github Actions to create
On Sunday, 23 February 2020 at 17:14:33 UTC, Per Nordlöw wrote:
I would like to setup auto-generation of online documentation
for my public D libraries residing on Github and Gitlab.
What alternatives do I have?
for gitlab they have a system of pages that's quite easy to setup:
something
On Sunday, 23 February 2020 at 17:38:35 UTC, Per Nordlöw wrote:
On Sunday, 23 February 2020 at 17:18:48 UTC, Andre Pany wrote:
Example: http://code.dlang.org/packages/arsd-official
Click on the documentation link.
Beside that you can use e.g. Github Actions to create
documentation.
Kind
On Sunday, 23 February 2020 at 17:18:48 UTC, Andre Pany wrote:
Example: http://code.dlang.org/packages/arsd-official
Click on the documentation link.
Beside that you can use e.g. Github Actions to create
documentation.
Kind regards
Andre
Thanks!
How do I check which dmd or dub command
On Sunday, 23 February 2020 at 17:14:33 UTC, Per Nordlöw wrote:
I would like to setup auto-generation of online documentation
for my public D libraries residing on Github and Gitlab.
What alternatives do I have?
If your Dub package is registered on code.dlang.org, this is
automatically
On Sunday, 23 February 2020 at 17:14:33 UTC, Per Nordlöw wrote:
I would like to setup auto-generation of online documentation
for my public D libraries residing on Github and Gitlab.
What alternatives do I have?
I'm thinking something like http://ddocs.org announced here
https
I would like to setup auto-generation of online documentation for
my public D libraries residing on Github and Gitlab.
What alternatives do I have?
Thanks for the excellent replies.
On Friday, 7 February 2020 at 08:52:44 UTC, mark wrote:
Some languages support this kind of thing:
if ((var x = expression) > 50)
print(x, " is > 50")
Is there anything similar in D?
Yes assuming that the expression is bool evaluable. This includes
- pointers: `if (auto p
:
string[string] dict;
if (auto p = "key" in dict) {
writeln(*p);
}
That works because the 'in' operator on aa's returns a pointer,
which can be compared to bool.
Some languages support this kind of thing:
if ((var x = expression) > 50)
print(x, " is > 50")
Is there anything similar in D?
On Thu, Jan 30, 2020 at 09:37:40AM +, Michael via Digitalmars-d-learn wrote:
[...]
> auto elements = buf.to!string.strip.split(" ").filter!(a => a != "");
>
> That line strips white space from buf, splits it, removes empty
> elements and returns an arra
On Thursday, January 30, 2020 2:37:40 AM MST Michael via Digitalmars-d-learn
wrote:
> auto is surely a nice feature. Nonetheless I'd prefer to use
> explicit types. So when reading a code and I see the auto keyword
> I also have to find out what kind of type is meant.
>
> I have
auto is surely a nice feature. Nonetheless I'd prefer to use
explicit types. So when reading a code and I see the auto keyword
I also have to find out what kind of type is meant.
I have a line of code that looks like this:
auto elements = buf.to!string.strip.split(" &quo
On Friday, 6 December 2019 at 23:25:30 UTC, Johannes Loher wrote:
On Tuesday, 3 December 2019 at 10:06:22 UTC, Mike Parker wrote:
On Tuesday, 3 December 2019 at 10:03:22 UTC, Basile B. wrote:
That's interesting details of D developement. Since you reply
to the first message I think you have
On Tuesday, 3 December 2019 at 10:06:22 UTC, Mike Parker wrote:
On Tuesday, 3 December 2019 at 10:03:22 UTC, Basile B. wrote:
That's interesting details of D developement. Since you reply
to the first message I think you have not followed but in the
last reply I told that maybe we should be
On Wednesday, 4 December 2019 at 12:54:34 UTC, Basile B. wrote:
On Wednesday, 4 December 2019 at 03:17:27 UTC, Adam D. Ruppe
wrote:
On Wednesday, 4 December 2019 at 01:28:00 UTC, H. S. Teoh
wrote:
typeof(return) is one of the lesser known cool things about D
that make it so cool. Somebody
On Wednesday, 4 December 2019 at 03:17:27 UTC, Adam D. Ruppe
wrote:
On Wednesday, 4 December 2019 at 01:28:00 UTC, H. S. Teoh wrote:
typeof(return) is one of the lesser known cool things about D
that make it so cool. Somebody should write an article about
it to raise awareness of it. :-D
via
>
> Digitalmars-d- learn wrote:
>> I wish something like this was possible, until I change the
>> return type of `alwaysReturnNull` from `void*` to `auto`.
>>
>>
>> ---
>> class A {}
>> class B {}
>>
>> auto alwaysReturnNull() // void
On Tuesday, 3 December 2019 at 23:44:59 UTC, mipri wrote:
On Tuesday, 3 December 2019 at 10:13:30 UTC, mipri wrote:
Speaking of nice stuff and aliases, suppose you want to
return a nice tuple with named elements?
Option 1: auto
auto option1() {
return tuple!(int, "apples&
On Wednesday, 4 December 2019 at 01:28:00 UTC, H. S. Teoh wrote:
typeof(return) is one of the lesser known cool things about D
that make it so cool. Somebody should write an article about
it to raise awareness of it. :-D
you know i probably will write about that next week. so be sure
to
On Wed, Dec 04, 2019 at 01:01:04AM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Tuesday, 3 December 2019 at 23:44:59 UTC, mipri wrote:
> > Option 4: typeof(return)
>
> typeof(return) is super cool for like option type things too!
typeof(return) is one of the lesser known cool things
On Tuesday, 3 December 2019 at 23:44:59 UTC, mipri wrote:
Option 4: typeof(return)
typeof(return) is super cool for like option type things too!
On Tuesday, 3 December 2019 at 10:13:30 UTC, mipri wrote:
Speaking of nice stuff and aliases, suppose you want to
return a nice tuple with named elements?
Option 1: auto
auto option1() {
return tuple!(int, "apples", int, "oranges")(1, 2);
}
Option 2: redu
On Tuesday, 3 December 2019 at 22:11:39 UTC, Meta wrote:
On Tuesday, 3 December 2019 at 17:45:27 UTC, H. S. Teoh wrote:
The thing is, `void` means "no return type" (or "no type" in
some contexts), i.e., void == TBottom in that case.
Not *quite* correct. void is not a bottom type; it's a unit
On Tuesday, 3 December 2019 at 17:45:27 UTC, H. S. Teoh wrote:
The thing is, `void` means "no return type" (or "no type" in
some contexts), i.e., void == TBottom in that case.
Not *quite* correct. void is not a bottom type; it's a unit type,
meaning that it's a type with only 1 value (as is
On Tue, Dec 03, 2019 at 09:08:55PM +, Paul Backus via Digitalmars-d-learn
wrote:
> On Tuesday, 3 December 2019 at 17:45:27 UTC, H. S. Teoh wrote:
> > The thing is, `void` means "no return type" (or "no type" in some
> > contexts), i.e., void == TBottom in that case.
>
> This is incorrect.
On Tuesday, 3 December 2019 at 17:45:27 UTC, H. S. Teoh wrote:
The thing is, `void` means "no return type" (or "no type" in
some contexts), i.e., void == TBottom in that case.
This is incorrect. `void` as a return type is a unit type; that
is, a type with exactly one value. A function with a
On Tue, Dec 03, 2019 at 03:19:02AM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Tuesday, December 3, 2019 3:03:22 AM MST Basile B. via Digitalmars-d-
> learn wrote:
[...]
> > [...] maybe we should be able to name the type of null. I think this
> > relates to TBottom too a bit.
>
>
On Tuesday, December 3, 2019 3:23:20 AM MST Basile B. via Digitalmars-d-
learn wrote:
> On Tuesday, 3 December 2019 at 10:19:02 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, December 3, 2019 3:03:22 AM MST Basile B. via
> >
> > Digitalmars-d- learn wrote:
> >> [...]
> >
> > There isn't much
On Tuesday, 3 December 2019 at 10:19:02 UTC, Jonathan M Davis
wrote:
On Tuesday, December 3, 2019 3:03:22 AM MST Basile B. via
Digitalmars-d- learn wrote:
[...]
There isn't much point in giving the type of null an explicit
name given that it doesn't come up very often, and typeof(null)
is
> >> I wish something like this was possible, until I change the
> >> return type of `alwaysReturnNull` from `void*` to `auto`.
> >>
> >>
> >> ---
> >> class A {}
> >> class B {}
> >>
> >> auto alwaysReturnNull() /
`auto` or
`typeof(null)`.
You can still create an alias anyway :)
alias TypeNull = typeof(null);
Speaking of nice stuff and aliases, suppose you want to
return a nice tuple with named elements?
Option 1: auto
auto option1() {
return tuple!(int, "apples", int, "
On Tuesday, 3 December 2019 at 10:06:22 UTC, Mike Parker wrote:
On Tuesday, 3 December 2019 at 10:03:22 UTC, Basile B. wrote:
That's interesting details of D developement. Since you reply
to the first message I think you have not followed but in the
last reply I told that maybe we should be
On Tuesday, 3 December 2019 at 10:03:22 UTC, Basile B. wrote:
That's interesting details of D developement. Since you reply
to the first message I think you have not followed but in the
last reply I told that maybe we should be able to name the type
of null. I think this relates to TBottom
On Tuesday, 3 December 2019 at 09:48:39 UTC, Basile B. wrote:
You see what surprises me here is that we cannot express the
special type that is `TypeNull` and that can only have one
value (`null`) so instead we have to use `auto` or
`typeof(null)`.
You can still create an alias anyway
On Tuesday, 3 December 2019 at 09:58:36 UTC, Jonathan M Davis
wrote:
On Tuesday, December 3, 2019 12:12:18 AM MST Basile B. via
Digitalmars-d- learn wrote:
I wish something like this was possible, until I change the
return type of `alwaysReturnNull` from `void*` to `auto`.
---
class
On Tuesday, December 3, 2019 12:12:18 AM MST Basile B. via Digitalmars-d-
learn wrote:
> I wish something like this was possible, until I change the
> return type of `alwaysReturnNull` from `void*` to `auto`.
>
>
> ---
> class A {}
> class B {}
>
> auto alwaysReturnNul
to A
}
still nice tho.
Why not [1]?
[1] typeof(null) alwaysReturnNull() { ... }
Andrea
Yeah nice, that works instead of auto.
That reminds me of the discussion about TBottom.
You see what surprises me here is that we cannot express the
special type that is `TypeNull` and that can only have one
) alwaysReturnNull() { ... }
Andrea
Yeah nice, that works instead of auto.
That reminds me of the discussion about TBottom.
On Tuesday, 3 December 2019 at 07:24:31 UTC, Basile B. wrote:
A testA()
{
return alwaysReturnNull(); // Tnull can be implictly
converted to A
}
still nice tho.
Why not [1]?
[1] typeof(null) alwaysReturnNull() { ... }
Andrea
On Tuesday, 3 December 2019 at 07:12:18 UTC, Basile B. wrote:
I wish something like this was possible, until I change the
return type of `alwaysReturnNull` from `void*` to `auto`.
---
class A {}
class B {}
auto alwaysReturnNull() // void*, don't compile
{
writeln();
return null
I wish something like this was possible, until I change the
return type of `alwaysReturnNull` from `void*` to `auto`.
---
class A {}
class B {}
auto alwaysReturnNull() // void*, don't compile
{
writeln();
return null;
}
A testA()
{
return alwaysReturnNull();
}
B testB
On Friday, 16 August 2019 at 16:22:27 UTC, Jonathan M Davis wrote:
[...]
Thanks very much again, very helpful explain.
I use pass by ref scope instead "return TreeRange.__ctor();" to
workround this issue.
On Friday, August 16, 2019 8:14:52 AM MDT Newbie2019 via Digitalmars-d-learn
wrote:
> On Friday, 16 August 2019 at 13:51:49 UTC, Jonathan M Davis wrote:
> > It is not possible to prevent moving in D as things currently
> > stand. DIP 1014 will need to be implemented to either hook into
> > moves
On Friday, 16 August 2019 at 13:51:49 UTC, Jonathan M Davis wrote:
It is not possible to prevent moving in D as things currently
stand. DIP 1014 will need to be implemented to either hook into
moves or to prevent them. However, once DIP 1014 has been
implemented, I would expect the result to
@disable this() ;
> > @disable this(this) ;
> >
> > }
> > struct Tree {
> >
> > ref auto getRange() return scope {
> >
> > return TreeRange!T(_root);
> >
> > }
> >
> > }
> > Tree tree;
> > auto range
On Friday, 16 August 2019 at 12:23:01 UTC, Newbie2019 wrote:
I has this simple function has some memory bugs:
---
struct TreeRange {
@disable this() ;
@disable this(this) ;
}
struct Tree {
ref auto getRange() return scope {
return TreeRange!T(_root
I has this simple function has some memory bugs:
---
struct TreeRange {
@disable this() ;
@disable this(this) ;
}
struct Tree {
ref auto getRange() return scope {
return TreeRange!T(_root);
}
}
Tree tree;
auto range = tree.getRange
Am Tue, 30 Jul 2019 15:19:44 +1200 schrieb rikki cattermole:
> On 30/07/2019 4:11 AM, Eduard Staniloiu wrote:
>> Cheers, everybody
>>
>> I'm working on this as part of my GSoC project [0].
>>
>> I'm working on building gdc with the auto-generated `frontend.h` [
On 30/07/2019 4:11 AM, Eduard Staniloiu wrote:
Cheers, everybody
I'm working on this as part of my GSoC project [0].
I'm working on building gdc with the auto-generated `frontend.h` [1],
but I'm having some issues
There are functions in dmd that don't have an `extern (C)` or `extern
(C
Cheers, everybody
I'm working on this as part of my GSoC project [0].
I'm working on building gdc with the auto-generated `frontend.h`
[1], but I'm having some issues
There are functions in dmd that don't have an `extern (C)` or
`extern (C++)` but they are used by gdc (are exposed in `.h
On Monday, 11 March 2019 at 22:29:05 UTC, aliak wrote:
[...]
Here's a much reduces test case:
struct W(T) {}
struct S {
int* data;
}
template match1(alias handler) {
auto ref match1(T)(inout auto ref W!T w) {
return handler();
}
}
template match2(alias handler
On Monday, 11 March 2019 at 22:29:05 UTC, aliak wrote:
Hi,
I have an error that says "Error: returning `match1(opt)`
escapes a reference to parameter `opt`, perhaps annotate with
`return`".
[...]
Ok, I've found out something else. It only happens when you're
returning a type that has an
I don't go through the "match2" template? Any
help would be much appreciated.
---
template match1(handlers...) {
auto ref match1(T)(inout auto ref Optional!T opt) { // remove
inout, it works
if (opt.empty) {
return handlers[1]();
} else {
On Tuesday, 21 August 2018 at 21:37:00 UTC, QueenSvetlana wrote:
I had a misunderstanding about the keyword auto because I
wrongfully believed that it made the code like Python
Exactly, you are thinking still like D is Python or also
dynamically typed. :) You will get when compiling errors
On Tuesday, 21 August 2018 at 18:44:15 UTC, Jim Balter wrote:
Python is not statically typed; D is. Why are you talking about
Python? You asked whether D's auto is like C#'s var ... it is,
but it doesn't have C#'s pointless restriction of not being
allowed for non-local declarations.
I think
On Tuesday, August 21, 2018 12:22:42 PM MDT QueenSvetlana via Digitalmars-d-
learn wrote:
> On Monday, 20 August 2018 at 17:55:11 UTC, JN wrote:
> > class Foo
> > {
> >
> > auto bar;
> >
> > }
> >
> > because now the compiler doesn't k
On Tuesday, August 21, 2018 9:04:31 AM MDT Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 8/20/18 9:15 PM, Mike Parker wrote:
> > I tend to use type inference liberally, almost always with
> > const/immutbale locals, though I tend to use auto only when the type
> >
On Tuesday, 21 August 2018 at 18:18:25 UTC, QueenSvetlana wrote:
On Tuesday, 21 August 2018 at 16:15:32 UTC, XavierAP wrote:
Only if someone
likes "Type x = new Type()" instead of "auto x = new Type()" I
would say they're clearly wrong.
As you stated it's up to the progra
On Monday, 20 August 2018 at 17:55:11 UTC, JN wrote:
class Foo
{
auto bar;
}
because now the compiler doesn't know what type 'bar' is
supposed to be.
Just to clarify, even if I set bar in the constructor, I can't
declare it with auto first, correct? I would have to declare a
specific
On Tuesday, 21 August 2018 at 16:15:32 UTC, XavierAP wrote:
Only if someone
likes "Type x = new Type()" instead of "auto x = new Type()" I
would say they're clearly wrong.
As you stated it's up to the programmer to decided. I'm in favor
of Type x = new Type() b
On Monday, 20 August 2018 at 17:52:17 UTC, QueenSvetlana wrote:
So I can't declare class level variables with auto, correct?
only local method variables?
One difference between D's auto and C#'s var or C++'s auto is
that the latter languages allow automatically typed declarations
only
On 8/20/18 9:15 PM, Mike Parker wrote:
I tend to use type inference liberally, almost always with
const/immutbale locals, though I tend to use auto only when the type
name is longer than four characters. For me, it's a nice way to save
keystrokes. Some take a dim view of that approach
On Monday, 20 August 2018 at 17:24:19 UTC, QueenSvetlana wrote:
I'm struggling to understand what the auto keyword is for and
it's appropriate uses. From research, it seems to share the
same capabilities as the var keyword in C#.
auto is one of the most misunderstood understood features
On Monday, 20 August 2018 at 17:52:17 UTC, QueenSvetlana wrote:
Great!
So I can't declare class level variables with auto, correct?
only local method variables?
You can, globals, class members:
class Foo
{
auto bar = "hi";
}
Foo.bar will be of string type here, because "
On Monday, 20 August 2018 at 17:52:17 UTC, QueenSvetlana wrote:
Great!
So I can't declare class level variables with auto, correct?
only local method variables?
You can use auto if you're setting the class level variable to a
default.
class X {
auto i = 42; // i will be an int
}
Great!
So I can't declare class level variables with auto, correct? only
local method variables?
On Monday, 20 August 2018 at 17:24:19 UTC, QueenSvetlana wrote:
I'm new to D programming, but have I have a background with
Python.
I'm struggling to understand what the auto keyword is for and
it's appropriate uses. From research, it seems to share the
same capabilities as the var keyword
I'm new to D programming, but have I have a background with
Python.
I'm struggling to understand what the auto keyword is for and
it's appropriate uses. From research, it seems to share the same
capabilities as the var keyword in C#. From the C# documentation,
it states:
https
n the compiler.
>
> I could not find any elucidation of the meaning of
>
> auto
>
> when used as a return type of a function.
It's not valid D code. The ddoc version of the documentation shows the
actual signature:
https://dlang.org/phobos/std_stdio.html#byChunk
If t
On Friday, 3 August 2018 at 17:27:07 UTC, Adam D. Ruppe wrote:
But remember, this is documentation that just happens to look
like code, so it is intended to be legible by people rather
than the compiler.
I could not find any elucidation of the meaning of
auto
when used as a return type
On Friday, 3 August 2018 at 17:16:14 UTC, kdevel wrote:
But that indented "code" is not syntactically valid D. Isn't it?
Right, it would give an error if actually compiled.
But remember, this is documentation that just happens to look
like code, so it is intended to be legible by people
On Friday, 3 August 2018 at 17:06:16 UTC, Adam D. Ruppe wrote:
On Friday, 3 August 2018 at 16:58:26 UTC, kdevel wrote:
What does
auto std.stdio.File.ByChunkImpl byChunk (
ulong chunkSize
);
on https://dlang.org/library/std/stdio/file.by_chunk.html mean?
It looks like ddox trying
On Friday, 3 August 2018 at 16:58:26 UTC, kdevel wrote:
What does
auto std.stdio.File.ByChunkImpl byChunk (
ulong chunkSize
);
on https://dlang.org/library/std/stdio/file.by_chunk.html mean?
It looks like ddox trying to tell you what the auto actually is.
But it returns
On Friday, 3 August 2018 at 16:58:26 UTC, kdevel wrote:
What does
auto std.stdio.File.ByChunkImpl byChunk (
ulong chunkSize
);
on https://dlang.org/library/std/stdio/file.by_chunk.html mean?
Is that
a (forward) declaration of a function named byChunk taking a
single
ulong argument
What does
auto std.stdio.File.ByChunkImpl byChunk (
ulong chunkSize
);
on https://dlang.org/library/std/stdio/file.by_chunk.html mean?
Is that
a (forward) declaration of a function named byChunk taking a
single
ulong argument name chunkSize. But what does that function return?
Thankyou Ali.
Timoses.
I did try DiamondMVC for a bit, but I found that there is more
help out there for Vibe.d. So I reverted back to using that. And
the Dependency Injection in Diamond MVC brings all the obscurity
that spring has which makes debugging more of a guessing game
than a
On Monday, 16 July 2018 at 08:28:06 UTC, Timoses wrote:
On Sunday, 15 July 2018 at 00:25:22 UTC, Venkat wrote:
[...]
I don't believe there currently exists a tool to rebuild the
Diet templates on the fly. The Diet templates require a step
during compilation (I think), so that the entire
On Sunday, 15 July 2018 at 00:25:22 UTC, Venkat wrote:
I am writing a simple vibe.d app. The following is what I do
right now.
- I make changes.
- build
- Restart the server.
Is there any tool that will auto publish my changes as I save
them ? I am using Visual Studio Code.
Thanks
Venkat
On Sunday, 15 July 2018 at 00:25:22 UTC, Venkat wrote:
I am writing a simple vibe.d app. The following is what I do
right now.
- I make changes.
- build
- Restart the server.
Is there any tool that will auto publish my changes as I save
them ? I am using Visual Studio Code.
Thanks
Venkat
An extension to the question. Is something like auto publish that
even possible ? Or the dumb guy from java world don't know what
he talkin' 'bout ?
I am writing a simple vibe.d app. The following is what I do
right now.
- I make changes.
- build
- Restart the server.
Is there any tool that will auto publish my changes as I save
them ? I am using Visual Studio Code.
Thanks
Venkat
On 07/04/2018 05:59 PM, Timoses wrote:
There's an empty 19.10.10 point without content[3] : D. Maybe a
placeholder?
[...]
[3]: https://dlang.org/spec/function.html#inout-functions
Just a bug.
https://github.com/dlang/dlang.org/pull/2407
On Wednesday, 4 July 2018 at 15:12:15 UTC, Jonathan M Davis wrote:
You can make opIndex inout instead of const. That way, inout
applies to the invisible this reference, just like it would
with const.
Awww, thanks! I was kinda hovering around this[1] section and
didn't quite see the
On Wednesday, July 04, 2018 14:07:35 Timoses via Digitalmars-d-learn wrote:
> How can I return inferred storage class from interface functions?
> I can't use auto as return value in interface. Neither can I use
> "inout" as I don't pass a parameter.
>
> // Re
On Wednesday, 4 July 2018 at 14:07:35 UTC, Timoses wrote:
How can I return inferred storage class from interface
functions?
I can't use auto as return value in interface. Neither can I
use "inout" as I don't pass a parameter.
// Ref Type
inte
How can I return inferred storage class from interface functions?
I can't use auto as return value in interface. Neither can I use
"inout" as I don't pass a parameter.
// Ref Type
interface IRef
{
Ref opIndex(size_t idx) const;
}
hat may make more sense (both for type sanity and for code reuse) is
to wrap your call to filter into one place so it can be used wherever
you need it:
auto wrapStream(S)(S str) { return str.filter!(x => x == myMessage); }
class b
{
typeof(wrapStream(a.init.myStream)()) mySubStream;
}
void myF
On Tuesday, May 22, 2018 10:40:55 Robert M. Münch via Digitalmars-d-learn
wrote:
> This would require one wrap function per different lambda, right?
> Assume I have 50-100 of these. Maybe the myMessage value can be given
> as parameter and with this becomes more like a "filter factory". Not
>
On Tuesday, May 22, 2018 10:43:38 Robert M. Münch via Digitalmars-d-learn
wrote:
> On 2018-05-21 20:17:04 +, Jonathan M Davis said:
> > On Monday, May 21, 2018 16:05:00 Steven Schveighoffer via Digitalmars-d-
> >
> > learn wrote:
> >> Well one thing that seems clear from this example -- we
and for code reuse) is
to wrap your call to filter into one place so it can be used wherever
you need it:
auto wrapStream(S)(S str) { return str.filter!(x => x == myMessage); }
class b
{
typeof(wrapStream(a.init.myStream)()) mySubStream;
}
void myFunc() {
a myA = new a;
b myB = ne
On 2018-05-21 20:17:04 +, Jonathan M Davis said:
On Monday, May 21, 2018 16:05:00 Steven Schveighoffer via Digitalmars-d-
learn wrote:
Well one thing that seems clear from this example -- we now have
__traits(isSame) to tell if lambdas are the same, but it looks like the
compiler doesn't
101 - 200 of 695 matches
Mail list logo
