On 8/28/2018 6:39 AM, Iain Buclaw wrote:
Template emission strategy is a mess, we're better off just instantiating all
templates in all compilation units, and let the compiler decide whatever to
discard. Even -allinst does not instantiate enough to allow the compiler to make
such decisions
H. S. Teoh wrote:
> On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via Digitalmars-d wrote:
> [...]
> Actually, I think C++ const is not very useful, because it guarantees
> nothing. At the most, it's just a sanity checker to make sure the
> programmer didn't accidentally do something dumb. But
On 8/23/2018 6:10 AM, Atila Neves wrote:
--
struct S {
int x;
@safe int* foo() { return }
}
--
% dmd -o- -dip1000 foo.d
% echo $?
0
struct S {
int x;
@safe int* foo() { return }
}
int* bar() {
S s;
return s.foo();
}
dmd test -dip1000
test.d(3):
On Wednesday, 29 August 2018 at 05:04:22 UTC, Walter Bright wrote:
On 8/25/2018 4:09 AM, Nicholas Wilson wrote:
On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright
wrote:
I'm not hostile to debate. I just don't care for "this is
uncharted territory, so let's do nothing" which has been
On 8/28/2018 6:12 AM, Steven Schveighoffer wrote:
So this would mean a member function would have to be refactored into a
different function with a different calling syntax. i.e:
x.foo(target);
would have to be refactored to:
target.foo(x);
or foo(target, x);
Maybe it should be anyway.
On 8/25/2018 4:09 AM, Nicholas Wilson wrote:
On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright wrote:
I'm not hostile to debate. I just don't care for "this is uncharted territory,
so let's do nothing" which has been going on for probably 4 years now,
coincident with "scope is
On 8/25/2018 5:42 AM, Chris M. wrote:
What about my other point then on the syntax? I think something similar to what
I suggested would be a much more flexible solution and is worth considering.
Much more work would be needed to make that a proposal.
On Tuesday, 28 August 2018 at 23:27:09 UTC, Nick Sabalausky wrote:
On Tuesday, 28 August 2018 at 21:57:28 UTC, solidstate1991
wrote:
Thanks to my education, I first wanted to approach every
problems in programming from an object-oriented viewpoint,
since that was the only one we were taught.
https://issues.dlang.org/show_bug.cgi?id=19203
--- Comment #1 from Nicholas Wilson ---
s/isArrayLike/hasPopBack
--
https://issues.dlang.org/show_bug.cgi?id=19203
Issue ID: 19203
Summary: alias this to a bool behaves both inconsistently and
incorrectly with static assert
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
On Tue, 28 Aug 2018 at 19:00, Walter Bright via Digitalmars-d
wrote:
>
> There's been some talk of adding a "mutable" qualifier for fields, which would
> stop the transitivity of const at that point. But it has problems, such as
> what
> happens with opaque types. The compiler can no longer
On Tue, 28 Aug 2018 at 10:54, H. S. Teoh via Digitalmars-d
wrote:
>
> On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via Digitalmars-d wrote:
> [...]
> > The reality is though, that D's const is not actually very useful, and
> > C++'s const is.
>
> Actually, I think C++ const is not very useful,
There's been some talk of adding a "mutable" qualifier for fields, which would
stop the transitivity of const at that point. But it has problems, such as what
happens with opaque types. The compiler can no longer check them, and hence will
have to assume they contain mutable members.
Thanks, that's a good explanation of the point of the differences between const
and immutable.
On Tuesday, 28 August 2018 at 20:32:29 UTC, H. S. Teoh wrote:
On Tue, Aug 28, 2018 at 07:39:20PM +, tide via
Digitalmars-d wrote:
On Tuesday, 28 August 2018 at 17:02:46 UTC, H. S. Teoh wrote:
> On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via
> Digitalmars-d wrote: [...]
> >
https://issues.dlang.org/show_bug.cgi?id=19202
Issue ID: 19202
Summary: deprecated eponymous template prints no warning
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
On Tuesday, 28 August 2018 at 21:57:28 UTC, solidstate1991 wrote:
Thanks to my education, I first wanted to approach every
problems in programming from an object-oriented viewpoint,
since that was the only one we were taught.
Sounds like you were more or less lucky compared to average:
On Tuesday, 28 August 2018 at 20:37:05 UTC, Everlast wrote:
Also, the biggest complaint is that when we use [] attached to
a type it has a specific meaning as "an array of". e.g., int[]
means an array of int's.
But int[] a... then changes as we don't have an array of int's
any more but
On Tuesday, 28 August 2018 at 11:30:20 UTC, JN wrote:
On Tuesday, 28 August 2018 at 08:39:20 UTC, bauss wrote:
The following language is a dangerous competitor to D.
https://github.com/joaomilho/Enterprise
I often feel like this kind of 'jokes' are trying too hard.
FizzBuzz Enterprise was
On Tuesday, 28 August 2018 at 20:39:16 UTC, aliak wrote:
Hi,
I'm trying to do something similar to what Kotlin allows with
assigning to member variables from a map. The syntax is very
readable and looks like:
class User(val map: Map) {
val name: String by map
val age: Int by map
On Tuesday, 28 August 2018 at 19:40:36 UTC, Paul Backus wrote:
On Tuesday, 28 August 2018 at 19:09:38 UTC, Everlast wrote:
Yeah, I see the link paul posted. The actual syntax seems a
bit strange to me...
We don't do
A[] a
So it is not "logical".
foo(A...)(A a)
but if A is a specific
Hi,
I'm trying to do something similar to what Kotlin allows with
assigning to member variables from a map. The syntax is very
readable and looks like:
class User(val map: Map) {
val name: String by map
val age: Int by map
}
So I'm trying to do something similar in D:
mixin
On Tue, Aug 28, 2018 at 06:44:37PM +, aliak via Digitalmars-d wrote:
> On Tuesday, 28 August 2018 at 17:53:36 UTC, H. S. Teoh wrote:
> > On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via
> > > D has no way to express head-const, and it turns out it's a
> > > tremendously useful concept.
> >
On Tue, Aug 28, 2018 at 07:39:20PM +, tide via Digitalmars-d wrote:
> On Tuesday, 28 August 2018 at 17:02:46 UTC, H. S. Teoh wrote:
> > On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via
> > Digitalmars-d wrote: [...]
> > > There are still valid use cases where const should be
On 08/28/2018 04:39 AM, bauss wrote:
The following language is a dangerous competitor to D.
https://github.com/joaomilho/Enterprise
Truly a visionary for this Millennial age. The cloud-plans for
Enterprise Web 3.0 are particularly disruptive. I'm excited just
imagining the possibilities it
On Tue, 2018-08-28 at 03:36 +, John Belmonte via Digitalmars-d
wrote:
> On Wednesday, 22 August 2018 at 16:49:01 UTC, Russel Winder wrote:
> > Have you tried asyncio in the Python standard library? Is Trio
> > better?
>
> The library that Guido admits is a disaster?
>
On Tuesday, 28 August 2018 at 19:09:38 UTC, Everlast wrote:
Yeah, I see the link paul posted. The actual syntax seems a bit
strange to me...
We don't do
A[] a
So it is not "logical".
foo(A...)(A a)
but if A is a specific type we must do
foo(int[] a ...)
The actual syntax then looks
On Tuesday, 28 August 2018 at 17:02:46 UTC, H. S. Teoh wrote:
On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via
Digitalmars-d wrote: [...]
There are still valid use cases where const should be
"broken". One of them is mutex (another one caching). I have
very little experiance in
On Tuesday, 28 August 2018 at 19:09:38 UTC, Everlast wrote:
On Tuesday, 28 August 2018 at 12:00:50 UTC, bauss wrote:
On Sunday, 26 August 2018 at 02:26:58 UTC, Everlast wrote:
in fact, I'd rather see
void print(T)(T t, int... a)
You were actually close.
void print(T)(T t, int[] a ...);
On Tuesday, 28 August 2018 at 12:00:50 UTC, bauss wrote:
On Sunday, 26 August 2018 at 02:26:58 UTC, Everlast wrote:
in fact, I'd rather see
void print(T)(T t, int... a)
You were actually close.
void print(T)(T t, int[] a ...);
Yeah, I see the link paul posted. The actual syntax seems a
On Tuesday, 28 August 2018 at 13:27:28 UTC, Simen Kjærås wrote:
Now, as has been pointed out, that only work for
null-coalescing, not null-propagation. It seems writers of
Optional, Variant, SumType, and so on, have decided not to
support this out of the box, but rather wrap it separately,
https://issues.dlang.org/show_bug.cgi?id=19201
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
On Tuesday, 28 August 2018 at 17:53:36 UTC, H. S. Teoh wrote:
On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via
D has no way to express head-const, and it turns out it's a
tremendously useful concept.
I can live without head-const... but what *really* makes const
painful for me is the lack
On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via Digitalmars-d wrote:
[...]
> The reality is though, that D's const is not actually very useful, and
> C++'s const is.
Actually, I think C++ const is not very useful, because it guarantees
nothing. At the most, it's just a sanity checker to make
On Tue, 28 Aug 2018 at 00:55, Walter Bright via Digitalmars-d
wrote:
>
> On 8/26/2018 11:16 PM, Manu wrote:
> >> The code looks the same, and in fact, is about 98% the same.
> > This code appears to be a mechanical translation.
>
> It's not. It's by hand. But I had a specific goal of minimizing
https://issues.dlang.org/show_bug.cgi?id=19201
Iain Buclaw changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
On Tuesday, 28 August 2018 at 13:39:40 UTC, Iain Buclaw wrote:
On Thursday, 23 August 2018 at 15:35:45 UTC, Joakim wrote:
On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
On Thursday, 23 August 2018 at 06:58:13 UTC, Joakim wrote:
On Thursday, 23 August 2018 at 03:50:44 UTC,
On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via Digitalmars-d
wrote:
[...]
> There are still valid use cases where const should be "broken". One of
> them is mutex (another one caching). I have very little experiance in
> multi-threaded programming, but what do you think about
https://issues.dlang.org/show_bug.cgi?id=19201
Issue ID: 19201
Summary: Error: func called with argument types (ulong) matches
both: __c_long and __c_ulong
Product: D
Version: D2
Hardware: All
OS: All
On Mon, Aug 27, 2018 at 06:11:14PM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/27/2018 10:08 AM, H. S. Teoh wrote:
> > Const in D makes sense as-is. Though, granted, its infectiousness means
> > its scope is actually very narrow, and as a result, we ironically
> > can't use it in very
On Tuesday, 28 August 2018 at 12:34:50 UTC, Martin Tschierschke
wrote:
On Wednesday, 22 August 2018 at 10:28:32 UTC, Joakim wrote:
https://play.google.com/store/apps/details?id=com.termux=en
$ apt search ldc
Sorting... Done
Full Text Search... Done
ipcalc/stable 0.41 aarch64
Calculates IP
On Tuesday, 28 August 2018 at 13:38:39 UTC, spikespaz wrote:
The problem arises when he types
"google.com.hk/search?q={{query}}" (exact string)
AFAIK, google has a parameter to output results in utf8.
Hi all,
I have noticed that "protected static" doesn't work currently with
classes. In my case, I wanted to use "static immutable", but I have
tried regular static members and methods, and the same issue happens.
However, the puzzling part is that protected enums (which are a valid
We have a reasonably number (but quiet) Chinese user base, we should
really support big5 and its extensions out-right.
On 8/28/18 9:38 AM, spikespaz wrote:
I have a user who submitted a bug report for one of my projects. The
error is in std\encoding.d on line 2554.
The problem arises when he types "google.com.hk/search?q={{query}}"
(exact string) into this function:
https://github.com/dlang/phobos/blob/master/std/net/curl.d#L1197
get!ubyte will disable encoding.
On Tuesday, 28 August 2018 at 13:05:15 UTC, bauss wrote:
I'm not sure if there is a better way, but isInstanceOf
(std.traits) seems to work with a static foreach and a static
if.
template Qwerty(Values...)
{
static foreach (value; Values)
{
static if (!isInstanceOf!(Qaz,
On Tuesday, 28 August 2018 at 13:38:39 UTC, spikespaz wrote:
I have a user who submitted a bug report for one of my
projects. The error is in std\encoding.d on line 2554.
The problem arises when he types
"google.com.hk/search?q={{query}}" (exact string) into this
function:
import std.stdio : stdout, writeln;
writeln(__MODULE__, ":", __LINE__); stdout.flush;
Trace it that way. The flush is important.
I have a user who submitted a bug report for one of my projects.
The error is in std\encoding.d on line 2554.
The problem arises when he types
"google.com.hk/search?q={{query}}" (exact string) into this
function:
On Thursday, 23 August 2018 at 15:35:45 UTC, Joakim wrote:
On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
On Thursday, 23 August 2018 at 06:58:13 UTC, Joakim wrote:
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh
wrote:
[...]
Can you list what you or other Weka
On Monday, 27 August 2018 at 14:59:20 UTC, SG wrote:
On Monday, 27 August 2018 at 07:59:17 UTC, Simen Kjærås wrote:
That's the null propagation operator (?.). What SG asked for
is the null-coalescing operator (??). Of course, this can also
be implemented in D (albeit with a slight more
On Tuesday, 28 August 2018 at 12:28:19 UTC, Andrey wrote:
Hello,
Let we have two variadic templates:
template Qwerty(Values...) {}
template Qaz(alias type, Data...) {}
Now I want to add a constraint to "Qwerty" so that each type in
"Values" pack must be a "Qaz" template. I don't care about
On 8/24/18 10:25 PM, Walter Bright wrote:
On 8/23/2018 6:32 AM, Steven Schveighoffer wrote:
Furthermore any member function (or UFCS function for that matter)
REQUIRES the first parameter to be the aggregate. How do you make a
member function that stuffs the return into a different parameter
On Tuesday, 28 August 2018 at 10:18:29 UTC, John Colvin wrote:
I get the feeling from the talk that Andrei has some opinions
about how it should be done that aren't completely in line with
what has been proposed for the C++ standard.
Anyhow my implementation at
On Tuesday, 28 August 2018 at 13:05:15 UTC, bauss wrote:
On Tuesday, 28 August 2018 at 12:28:19 UTC, Andrey wrote:
Hello,
Let we have two variadic templates:
template Qwerty(Values...) {}
template Qaz(alias type, Data...) {}
Now I want to add a constraint to "Qwerty" so that each type
in
On Thursday, 23 August 2018 at 09:29:30 UTC, Nicholas Wilson
wrote:
On Thursday, 23 August 2018 at 07:00:01 UTC, Iain Buclaw wrote:
On Thursday, 23 August 2018 at 06:34:04 UTC, Shachar Shemesh
wrote:
On 23/08/18 09:17, Jacob Carlborg wrote:
I don't see why we just can't add support for scoped
On Tuesday, 28 August 2018 at 12:28:19 UTC, Andrey wrote:
Hello,
Let we have two variadic templates:
template Qwerty(Values...) {}
template Qaz(alias type, Data...) {}
Now I want to add a constraint to "Qwerty" so that each type in
"Values" pack must be a "Qaz" template. I don't care about
On Tuesday, 28 August 2018 at 12:28:19 UTC, Andrey wrote:
Hello,
Let we have two variadic templates:
template Qwerty(Values...) {}
template Qaz(alias type, Data...) {}
Now I want to add a constraint to "Qwerty" so that each type in
"Values" pack must be a "Qaz" template. I don't care about
https://issues.dlang.org/show_bug.cgi?id=19200
Issue ID: 19200
Summary: Variant operators don't overload correctly
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
On 8/24/18 10:28 PM, Walter Bright wrote:
On 8/23/2018 8:14 AM, Steven Schveighoffer wrote:
If I had to design a specific way to allow the common case to be easy,
but still provide a mechanism for the uncommon cases, I would say:
1. define a compiler-recognized attribute (e.g. @__sink).
2. If
Thanks for all your answers.
I'll have a look at the design and use casting if necessary.
On Wednesday, 22 August 2018 at 10:28:32 UTC, Joakim wrote:
https://play.google.com/store/apps/details?id=com.termux=en
$ apt search ldc
Sorting... Done
Full Text Search... Done
ipcalc/stable 0.41 aarch64
Calculates IP broadcast, network, Cisco wildcard mask, and
host ranges
ldc/stable
Hello,
Let we have two variadic templates:
template Qwerty(Values...) {}
template Qaz(alias type, Data...) {}
Now I want to add a constraint to "Qwerty" so that each type in
"Values" pack must be a "Qaz" template. I don't care about values
of "type" or "Data" in "Qaz".
How to do it in D?
On Sunday, 26 August 2018 at 02:26:58 UTC, Everlast wrote:
in fact, I'd rather see
void print(T)(T t, int... a)
You were actually close.
void print(T)(T t, int[] a ...);
On Tuesday, 28 August 2018 at 10:48:20 UTC, Ivo wrote:
I'm writing a basic server program and I want to handle each
connection received in a new thread.
So here is the code I'm trying to produce:
while(true) {
auto client = socket.accept();
spawn( , client);
}
void
while(true) {
auto client = socket.accept();
spawn(, cast(shared)client);
}
void handleConnection(shared Socket sclient) {
Socket client=cast()sclient;
//do stuff like receive and send
}
Maybe http://libpipeline.nongnu.org/ can be an inspiration.
On Tuesday, 28 August 2018 at 08:39:20 UTC, bauss wrote:
The following language is a dangerous competitor to D.
https://github.com/joaomilho/Enterprise
I often feel like this kind of 'jokes' are trying too hard.
FizzBuzz Enterprise was fun when it first came out, and I know
it's popular to
I'm writing a basic server program and I want to handle each
connection received in a new thread.
So here is the code I'm trying to produce:
while(true) {
auto client = socket.accept();
spawn( , client);
}
void handleConnection(Socket client) {
//do stuff like receive and send
}
On Thursday, 16 August 2018 at 20:37:33 UTC, Per Nordlöw wrote:
In
https://www.youtube.com/watch?v=nVzgkepAg5Y
Andrei describes his proposal for STL `Expected` planned to be
included in C++20.
Have anybody converted the C++ proposal to idiomatic D, yet?
Hopefully without the pointer-legacy
On Tuesday, 28 August 2018 at 08:44:26 UTC, Chris wrote:
Last but not least, if it's true that the D Foundation has
raised only 3.2K, then there's something seriously wrong.
The Foundation has significantly more than 3.2k. The Open
Collective account is relatively new and is but one
On 8/27/2018 7:02 AM, Don wrote:
I can explain this, since I did the original implementation.
[...]
Thank you, Don. And you do have my mad respect for figuring out Windows SEH.
On Tuesday, 28 August 2018 at 08:39:20 UTC, bauss wrote:
The following language is a dangerous competitor to D.
https://github.com/joaomilho/Enterprise
Thats very funny, but I found Rockstar even funnier.
On Tuesday, 28 August 2018 at 08:44:26 UTC, Chris wrote:
When people choose a programming language, there are several
boxes that have to be ticked, like for example:
- what's the future of language X? (guarantees, stability)
- how easy is it to get going (from "Hello world" to a complete
On Tue, Aug 28, 2018 at 8:40 AM Eugene Wissner via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Tuesday, 28 August 2018 at 06:18:28 UTC, Daniel Kozak wrote:
> > On Mon, Aug 27, 2018 at 7:55 PM Eugene Wissner via
> > Digitalmars-d-announce <
On Tuesday, 28 August 2018 at 07:30:01 UTC, Walter Bright wrote:
On 8/27/2018 2:14 AM, Chris wrote:
bad feeling about the way things are going atm.
I can quote you a lng list of problems that are obvious
only in hindsight, by world leading development teams.
Start by watching the
On Saturday, 25 August 2018 at 13:33:58 UTC, SG wrote:
1) I program in C# and I'm wondering if there is something like
?? (Null-Coalescing Operator) in D? (I remember some proposals
in the past).
Another example:
https://github.com/aliak00/optional/blob/master/source/optional/optional.d#L340
The following language is a dangerous competitor to D.
https://github.com/joaomilho/Enterprise
On Tuesday, 28 August 2018 at 07:53:34 UTC, Walter Bright wrote:
Let's take the much-maligned D const. It isn't C++ const (let's
call that "head-const", because that's what it is). Head-const
for a function parameter tells us very little about what may
happen to it in the function. You can
On 8/26/2018 11:16 PM, Manu wrote:
The code looks the same, and in fact, is about 98% the same.
This code appears to be a mechanical translation.
It's not. It's by hand. But I had a specific goal of minimizing the diffs, so
that if the translation didn't work, it reduced the number of places
On Tuesday, 28 August 2018 at 06:20:37 UTC, Sebastiaan Koppe
wrote:
On Tuesday, 28 August 2018 at 06:11:35 UTC, Jon Degenhardt
wrote:
The goal is to write the argument list once and use it to
create both the function and the Tuple alias. That way I could
create a large number of these function
On 8/27/2018 2:14 AM, Chris wrote:
On Sunday, 26 August 2018 at 22:44:05 UTC, Walter Bright wrote:
Because nobody thought about that issue before. A lot of things only become
apparent in hindsight.
QED. With this approach you do more harm than good. I have a bad feeling about
the way things
https://issues.dlang.org/show_bug.cgi?id=18104
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=18104
--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dlang.org
https://github.com/dlang/dlang.org/commit/9ad4c395470befec8293593fc8dfbdc906cfb56f
Fix Issue 18104: improve example showing that
On Monday, 27 August 2018 at 21:32:10 UTC, David Nadlinger wrote:
On Monday, 27 August 2018 at 20:47:08 UTC, Stefam Koch wrote:
generating it is not the problem but linking it on windows
currently requires the MS linker.
Is that true, though? DMD ships with LLD these days. — David
Really
On Tuesday, 28 August 2018 at 06:20:37 UTC, Sebastiaan Koppe
wrote:
On Tuesday, 28 August 2018 at 06:11:35 UTC, Jon Degenhardt
wrote:
The goal is to write the argument list once and use it to
create both the function and the Tuple alias. That way I could
create a large number of these function
On 28/08/2018 9:32 AM, David Nadlinger wrote:
On Monday, 27 August 2018 at 20:47:08 UTC, Stefam Koch wrote:
generating it is not the problem but linking it on windows currently
requires the MS linker.
Is that true, though? DMD ships with LLD these days. — David
And is 100% experimental on
On Monday, 27 August 2018 at 21:48:04 UTC, Alex wrote:
On Monday, 27 August 2018 at 19:36:29 UTC, aliak wrote:
Then Nullable!(int*) would be the same as int*. Or even better
maybe is to give a compiler error when you try and stuff a
nullable type inside a Nullable. Because ... why?
Isn't
On Tuesday, 28 August 2018 at 06:18:28 UTC, Daniel Kozak wrote:
On Mon, Aug 27, 2018 at 7:55 PM Eugene Wissner via
Digitalmars-d-announce < digitalmars-d-announce@puremagic.com>
wrote:
On Monday, 27 August 2018 at 17:23:04 UTC, Arun Chandrasekaran
wrote:
> 1. It would be good to print the
On Tuesday, 28 August 2018 at 06:11:35 UTC, Jon Degenhardt wrote:
The goal is to write the argument list once and use it to
create both the function and the Tuple alias. That way I could
create a large number of these function / arglist tuple pairs
with less brittleness.
--Jon
I would
On Tuesday, 28 August 2018 at 06:11:35 UTC, Jon Degenhardt wrote:
I'd like to create a Tuple alias representing a function's
parameter list. Is there a way to do this?
[...]
Are you aware of
https://dlang.org/phobos/std_traits.html#Parameters
On Mon, Aug 27, 2018 at 7:55 PM Eugene Wissner via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Monday, 27 August 2018 at 17:23:04 UTC, Arun Chandrasekaran
> wrote:
> > 1. It would be good to print the DMD frontend version with `gdc
> > --version`. It is helpful in
I'd like to create a Tuple alias representing a function's
parameter list. Is there a way to do this?
Here's an example creating a Tuple alias for a function's
parameters by hand:
import std.typecons: Tuple;
bool fn(string op, int v1, int v2)
{
switch (op)
{
94 matches
Mail list logo
