https://issues.dlang.org/show_bug.cgi?id=19037
--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos
https://github.com/dlang/phobos/commit/c1431b133bb26d3a777bdea0815c7212d1ff09d7
Use move/moveEmplace in Nullable
Fixes issue 19037.
On 7/27/2018 4:15 PM, Laeeth Isharc wrote:
Can you think of a pragmatic solution to Atila's problem?
One way is for the C++ => D translator to gather all the members of a namespace
before trying to emit them. Since D does not impose an order on declarations
(unlike C++) it is not constrained
https://issues.dlang.org/show_bug.cgi?id=19124
Issue ID: 19124
Summary: Investigate using RYU to convert floats to strings
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
On Friday, 27 July 2018 at 15:04:12 UTC, Abdulhaq wrote:
On Wednesday, 25 July 2018 at 23:27:45 UTC, Laeeth Isharc wrote:
But making predictions is a tricky thing and mostly of not
much value.
I'm really surprised to hear you say this - so much money in
the financial services is poured into
https://issues.dlang.org/show_bug.cgi?id=19123
Basile B. changed:
What|Removed |Added
CC||b2.t...@gmx.com
Severity|normal
On Friday, 27 July 2018 at 22:50:20 UTC, Walter Bright wrote:
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D compiler how to
mangle symbols.
Namespaces have semantic implications, too, such as overload
resolutions. A namespace introduces a new scope,
https://issues.dlang.org/show_bug.cgi?id=19123
Issue ID: 19123
Summary: -allinst gives undefined reference linker errors
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D
compiler how to mangle symbols.
Namespaces have semantic implications, too, such as overload resolutions. A
namespace introduces a new scope, not just a mangling.
> But why does this not compile?
>
https://issues.dlang.org/show_bug.cgi?id=19119
--- Comment #13 from Manu ---
(In reply to kinke from comment #12)
> Something very similar is apparently already done for GC-allocated structs -
> if they have a destructor, the TypeInfo pointer is stored right after the
> actual instance, and a
On Friday, 27 July 2018 at 03:41:29 UTC, Sameer Pradhan wrote:
During our Boston D Meetup today, we went through and
deconstructed Walter's wonderfully elegant blog post from 2012
called "Component Programming in D"
On 7/27/18 3:44 PM, Russel Winder wrote:
On Fri, 2018-07-27 at 15:25 -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[…]
Oh, it looks like you specified once. Hm... that seems to me like it
should work.
Looks like IOMode is ignored:
On Fri, 2018-07-27 at 15:25 -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[…]
>
> Oh, it looks like you specified once. Hm... that seems to me like it
> should work.
>
> Looks like IOMode is ignored:
>
> https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78c
>
On Friday, 27 July 2018 at 03:41:29 UTC, Sameer Pradhan wrote:
Therefore, after reading the word "Extension" in three
different contexts, I started wondering and various questions
came to mind, starting with---Whence came UFCS?
The answer I always say back in the day for the functionality was
https://issues.dlang.org/show_bug.cgi?id=19119
--- Comment #12 from ki...@gmx.net ---
Something very similar is apparently already done for GC-allocated structs - if
they have a destructor, the TypeInfo pointer is stored right after the actual
instance, and a specially marked GC block is
On 7/27/18 3:18 PM, Steven Schveighoffer wrote:
On 7/27/18 3:02 PM, Russel Winder wrote:
I have posted to the vibe.d forum, but I hate forums, and it looks like
a months worth of questions haven't been read yet, so please excuse
repeating here – I need an fairly definitive answer pdq in order
On 7/27/18 3:02 PM, Russel Winder wrote:
I have posted to the vibe.d forum, but I hate forums, and it looks like
a months worth of questions haven't been read yet, so please excuse
repeating here – I need an fairly definitive answer pdq in order to
finish my answer to the CVu Code Critique 112.
https://issues.dlang.org/show_bug.cgi?id=19119
--- Comment #11 from ki...@gmx.net ---
(In reply to Manu from comment #10)
> or maybe there's some opportunity to make gcnew wrap C++ class
> allocations in a thin D class that forwards the destructor?
I guess something like having specially-marked
https://issues.dlang.org/show_bug.cgi?id=19119
--- Comment #10 from Manu ---
Right, and that goes back to my original point; the GC doesn't know the memory
is a C++ class, and doesn't know how to destruct.
So either, use the GC under the assumption the destructor will never be
called... or
I have posted to the vibe.d forum, but I hate forums, and it looks like
a months worth of questions haven't been read yet, so please excuse
repeating here – I need an fairly definitive answer pdq in order to
finish my answer to the CVu Code Critique 112. The deadline is in three
days.
https://issues.dlang.org/show_bug.cgi?id=19119
--- Comment #9 from ki...@gmx.net ---
Ouch, I totally overlooked the missing fields on the D side too.
The GC now releases the memory correctly - without trying to destruct the
extern(C++) objects first (independent from virtual-ness of dtor), which
I had no idea of the DoD's Steelman requirements
(https://en.wikipedia.org/wiki/Steelman_language_requirements)
I found another documents that has the same table that was on the
website listed in an earlier post. Here are the individual links:
https://www.dwheeler.com/steelman/steeltab.htm
https://issues.dlang.org/show_bug.cgi?id=19073
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=19073
--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/druntime
https://github.com/dlang/druntime/commit/7ebe816eaeb83394558ae5467920eebc9ebde2d9
Fix Issue 19073 - core.internal.hash should not
On 27.07.2018 19:28, Atila Neves wrote:
I understand that being able to "reopen" namespaces in C++ is
contentious - anybody can add to the `std` namespace in their own code.
D doesn't have anything like it, and instead has packages and modules.
So far, so good.
But why does this not compile?
This limitation really seems to make no sense, especially since
you can split up a C++ namespace across multiple D modules, just
not inside a single module.
https://issues.dlang.org/show_bug.cgi?id=19119
--- Comment #8 from Manu ---
(In reply to Vladimir Marchevsky from comment #7)
> Sounds logical. I've tried to additionally export Bar, map it in D and also
> to add Foo::a and Foo::b to mapping to make it full. Problem has gone and it
> seems to
I understand that being able to "reopen" namespaces in C++ is
contentious - anybody can add to the `std` namespace in their own
code. D doesn't have anything like it, and instead has packages
and modules. So far, so good.
But why does this not compile?
extern(C++, ns) { void foo(); }
Wow! I am glad to see so many responses! Thanks for your
indulgence.
So, to summarize, the concept (no pun intended) has been around
for a while in D---originally in the context of arrays. It just
might have been a bug, or an unintended side-effect. I intend to
read the archival posts and
On Fri, Jul 27, 2018 at 03:41:29AM +, Sameer Pradhan via Digitalmars-d
wrote:
[...]
> Whence came UFCS?
[...]
As far as I know, UFCS came about from a particular interpretation of
TDPL (Andrei's book). Andrei was talking about the range API, and
inserted a little note about how native
On Friday, July 27, 2018 6:28:07 AM MDT Seb via Digitalmars-d wrote:
> On Friday, 27 July 2018 at 12:04:18 UTC, Jonathan M Davis wrote:
> > On Friday, July 27, 2018 5:03:50 AM MDT Seb via Digitalmars-d
> >
> > wrote:
> >> What do you think?
> >> --
> >>
> >> - Has the dmd/druntime
On Friday, July 27, 2018 8:09:02 AM MDT Simen Kjærås via Digitalmars-d
wrote:
> On Friday, 27 July 2018 at 13:38:26 UTC, Steven Schveighoffer
>
> wrote:
> > On 7/27/18 7:24 AM, Simen Kjærås wrote:
> >> Arrays' .reverse, .sort and others were added in 0.24, but I
> >> can't find a download for
On 7/27/18 10:09 AM, Simen Kjærås wrote:
On Friday, 27 July 2018 at 13:38:26 UTC, Steven Schveighoffer wrote:
On 7/27/18 7:24 AM, Simen Kjærås wrote:
Arrays' .reverse, .sort and others were added in 0.24, but I can't
find a download for anything before 0.50.
Reverse and sort were properties
On Friday, 27 July 2018 at 13:06:10 UTC, aliak wrote:
On Friday, 27 July 2018 at 13:05:07 UTC, aliak wrote:
https://run.dlang.io/is/lLrUiq
Sorry: https://run.dlang.io/is/20FUoj
Thanks, you are right, but it seems that I have reduced my issue
too much, as it still does not work with my
On Friday, 27 July 2018 at 14:48:06 UTC, Steven Schveighoffer
wrote:
On 7/27/18 9:10 AM, aliak wrote:
import std.traits: isMutable;
struct S {
immutable int i = 3;
}
pragma(msg, isMutable!S);
void main() {
S s;
s = S();
}
isMutable only takes the type into account, it doesn't
On Wednesday, 25 July 2018 at 23:27:45 UTC, Laeeth Isharc wrote:
But making predictions is a tricky thing and mostly of not much
value.
I'm really surprised to hear you say this - so much money in the
financial services is poured into making predictions, lots of
them and as fast as
On 7/23/18 2:39 PM, aliak wrote:
Hi,
I'm playing around with an Optional wrapper type. It stores a type T and
a bool that defines whether a value is defined or not:
struct Optional(T) {
T value;
bool defined = false;
this(U : T)(auto ref inout(U) value) inout {
this.value =
On 7/27/18 9:10 AM, aliak wrote:
import std.traits: isMutable;
struct S {
immutable int i = 3;
}
pragma(msg, isMutable!S);
void main() {
S s;
s = S();
}
isMutable only takes the type into account, it doesn't look to see if
all the internals are mutable.
It literally is
On Friday, 27 July 2018 at 14:31:24 UTC, Mike Parker wrote:
This is the earliest thread I could find in the archives, based
solely on searching for "array" in the title. I almost fell
down the rabbit hole reading some of those old threads, as the
ones I did look at tickled my memory.
On 7/27/18 9:29 AM, aliak wrote:
Ok, thanks to Simen from another post [0], I just figured out what the
correct constructor and factory method for a template wrapper should be:
https://run.dlang.io/is/S4vHzL
struct W(T) {
T val;
this(U : T, this This)(auto ref U val) {
On 7/23/18 8:02 AM, aliak wrote:
On Sunday, 22 July 2018 at 23:11:09 UTC, Ali Çehreli wrote:
Without much confidence on my side, first, I think you need to make
the constructor parameter inout(T) as well. Otherwise, you may be
making a const(W!T) initialized with a non-const T.
After that, I
On Friday, 27 July 2018 at 14:12:53 UTC, Mike Parker wrote:
On Friday, 27 July 2018 at 14:09:02 UTC, Simen Kjærås wrote:
From what I recall, UFCS for arrays were essentially a bug -
an unintended side effect of how the properties were
implemented. But it's been 15 years, so I can't really
https://issues.dlang.org/show_bug.cgi?id=19122
Issue ID: 19122
Summary: Multiple destruction of union members
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: safe
Severity:
On Friday, 27 July 2018 at 12:52:09 UTC, aliak wrote:
On Thursday, 26 July 2018 at 06:37:41 UTC, Simen Kjærås wrote:
As for assigning to Optional!(immutable int), the language
basically forbids this (cannot modify struct with immutable
members). It would, as you say, cause problems when you
On Friday, 27 July 2018 at 14:09:02 UTC, Simen Kjærås wrote:
From what I recall, UFCS for arrays were essentially a bug - an
unintended side effect of how the properties were implemented.
But it's been 15 years, so I can't really trust my memory. :p
You're not alone! That's how I
On 7/27/18 7:03 AM, Seb wrote:
This a thread to explore whether it would be feasible to do so.
Motivation
--
DRuntime and DMD heavily depend on each other.
It happens very often that a PR needs to touch both and then a
complicated three-step (or sometimes four-step PR series) needs
On Friday, 27 July 2018 at 13:38:26 UTC, Steven Schveighoffer
wrote:
Reverse and sort were properties (compiler built-ins), not
extensions. If it existed in 2002, it's safe to say it was
there pretty much from the beginning.
-Steve
I came to D in 2003. I recall this coming up in the
On Friday, 27 July 2018 at 13:38:26 UTC, Steven Schveighoffer
wrote:
On 7/27/18 7:24 AM, Simen Kjærås wrote:
Arrays' .reverse, .sort and others were added in 0.24, but I
can't find a download for anything before 0.50.
Reverse and sort were properties (compiler built-ins), not
extensions. If
On Friday, 27 July 2018 at 05:22:17 UTC, Joakim wrote:
On Friday, 27 July 2018 at 03:41:29 UTC, Sameer Pradhan wrote:
During our Boston D Meetup today, we went through and
deconstructed Walter's wonderfully elegant blog post from 2012
called "Component Programming in D"
[...]
Extension
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote:
This a thread to explore whether it would be feasible to do so.
Motivation
--
[...]
Not much.
- Do you have a better suggestion?
No.
- Would this break your workflow in a drastic way?
No, don't really use the official repos
On 7/27/18 7:24 AM, Simen Kjærås wrote:
On Friday, 27 July 2018 at 10:30:07 UTC, Jonathan M Davis wrote:
It evolved out of D's member function call syntax for arrays -
basically, for years before we had UFCS in D, we had UFCS for arrays.
However, when and how that was added to arrays, I don't
On Monday, 23 July 2018 at 14:46:32 UTC, Timoses wrote:
On Monday, 23 July 2018 at 12:02:58 UTC, aliak wrote:
[...]
Both of these seem to work (as you pointed out)
// immutable(W!int)
auto si = wrap!(int)(cast(immutable)3); // or
wrap(cast(immutable)3);
// W!(immutable(int))
import std.traits: isMutable;
struct S {
immutable int i = 3;
}
pragma(msg, isMutable!S);
void main() {
S s;
s = S();
}
And is there a trait that takes the transitivity of immutability
in to account?
Cheers,
- Ali
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote:
This a thread to explore whether it would be feasible to do so.
What do you think?
--
One is a compiler the other is a (optional!) library.
merging the two means forcing druntime onto people who want to
use dmd.
the
On Friday, 27 July 2018 at 13:05:07 UTC, aliak wrote:
https://run.dlang.io/is/lLrUiq
Sorry: https://run.dlang.io/is/20FUoj
On Friday, 27 July 2018 at 12:04:18 UTC, Jonathan M Davis wrote:
On Friday, July 27, 2018 5:03:50 AM MDT Seb via Digitalmars-d
wrote:
What do you think?
--
- Has the dmd/druntime split being annoying you too?
- Do you have a better suggestion?
- Would this break your workflow
On Friday, 27 July 2018 at 12:11:37 UTC, Peter Particle wrote:
Question is related to this:
https://dlang.org/spec/struct.html#disable_default_construction
struct S {
int x;
@disable this(); // Disables default construction
@disable this(this); // Disable copying
this(int
https://issues.dlang.org/show_bug.cgi?id=19119
--- Comment #7 from Vladimir Marchevsky ---
Sounds logical. I've tried to additionally export Bar, map it in D and also to
add Foo::a and Foo::b to mapping to make it full. Problem has gone and it seems
to work correct without crashes or memory
On Thursday, 26 July 2018 at 06:37:41 UTC, Simen Kjærås wrote:
On Wednesday, 25 July 2018 at 21:59:00 UTC, aliak wrote:
It needs to work with const as well and immutable too.
immutable a = 3;
auto b = -a; // is ok, should be ok with the optional as well.
Plus T can be a custom type as well
On Wednesday, 25 July 2018 at 21:59:52 UTC, Ali Çehreli wrote:
Somebody had posted an article here on how well different
languages matched certain requirements of a certain coding
safety standards.
I remember D was doing pretty well and I think Ada (or SPARK?)
was included as well. What
On Friday, 27 July 2018 at 12:02:50 UTC, Russel Winder wrote:
On Fri, 2018-07-27 at 11:03 +, Seb via Digitalmars-d wrote:
This a thread to explore whether it would be feasible to do so.
Motivation
--
DRuntime and DMD heavily depend on each other.
But DMD is only one of the
On Friday, 27 July 2018 at 12:04:18 UTC, Jonathan M Davis wrote:
On Friday, July 27, 2018 5:03:50 AM MDT Seb via Digitalmars-d
wrote:
What do you think?
--
- Has the dmd/druntime split being annoying you too?
- Do you have a better suggestion?
- Would this break your workflow
On Monday, 23 July 2018 at 14:26:17 UTC, Nick Treleaven wrote:
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature
wrote:
To reproduce the format issue, try to print the struct with
writefln!"%s"(MyDomainType()).
I implemented the compile time format string checking by
evaluating
Update:
https://github.com/dlang/dmd/pull/5830
Turns out unions with fields with destructors is **define
behavior**. I did not know this. Probably the spec needs updating.
So that pretty much alleviates the need for this DIP. Though I
kind of half-believe that this DIP is actually *better*
Question is related to this:
https://dlang.org/spec/struct.html#disable_default_construction
struct S {
int x;
@disable this(); // Disables default construction
@disable this(this); // Disable copying
this(int v) { x = v; }
}
struct T {
float y;
S s;
@disable
On Friday, 27 July 2018 at 11:50:11 UTC, Mark wrote:
On Friday, 27 July 2018 at 06:20:57 UTC, Stefan Koch wrote:
On Friday, 27 July 2018 at 04:56:01 UTC, Mark wrote:
Hello,
...
Have you tried using -profile-gc ?
No, I haven't. Ill give that a try and see what I find. Thanks!
Hmm,
+1 leave it
On Friday, 27 July 2018 at 11:44:10 UTC, aliak wrote:
A) I'd suggest "@nodestruct" instead, since it sounds like that
what it's supposed to do?
Yes-ish, but it's also supposed to fill the hole in the
typesystem created by T.init, and "you can only assign T.init to
types marked @nodestruct"
See what the program does when it consumes memory.
On Friday, July 27, 2018 5:03:50 AM MDT Seb via Digitalmars-d wrote:
> What do you think?
> --
>
> - Has the dmd/druntime split being annoying you too?
> - Do you have a better suggestion?
> - Would this break your workflow in a drastic way?
It would break all existing tools and
On Fri, 2018-07-27 at 11:03 +, Seb via Digitalmars-d wrote:
> This a thread to explore whether it would be feasible to do so.
>
> Motivation
> --
>
> DRuntime and DMD heavily depend on each other.
>
But DMD is only one of the compilers, there is LDC and GDC. Is Druntime
unique to
On Friday, 27 July 2018 at 06:20:57 UTC, Stefan Koch wrote:
On Friday, 27 July 2018 at 04:56:01 UTC, Mark wrote:
Hello,
...
Have you tried using -profile-gc ?
No, I haven't. Ill give that a try and see what I find. Thanks!
On Friday, 27 July 2018 at 09:30:00 UTC, FeepingCreature wrote:
A new UDA is introduced: @manualScoped. It is valid for fields
in structs and classes, as well as variables and parameters.
Fields marked with @manualScoped are not automatically
destructed on scope end.
For instance, a function
On 27 July 2018 at 13:32, Mike Franklin via Digitalmars-d
wrote:
> On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote:
>
>> What do you think?
>> --
>
>
> Also, is there any other compelling reasons besides the test dependency
> problem to motivate merging the two repositories?
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote:
What do you think?
--
Also, is there any other compelling reasons besides the test
dependency problem to motivate merging the two repositories?
What other benefits would it provide, if any?
Mike
https://issues.dlang.org/show_bug.cgi?id=19119
--- Comment #6 from anonymous4 ---
Shouldn't you declare class fields on the D side? How one can determine how
much memory to allocate for the instance?
--
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote:
- Do you have a better suggestion?
Do we have a rich enough CI API to recognize dependencies between
repositories? For example, if I create a local branch in my dmd
repository named `fix_bug` and a local branch in my druntime
repository
On Friday, 27 July 2018 at 10:30:07 UTC, Jonathan M Davis wrote:
It evolved out of D's member function call syntax for arrays -
basically, for years before we had UFCS in D, we had UFCS for
arrays. However, when and how that was added to arrays, I don't
know. I don't recall it ever not being
This a thread to explore whether it would be feasible to do so.
Motivation
--
DRuntime and DMD heavily depend on each other.
It happens very often that a PR needs to touch both and then a
complicated three-step (or sometimes four-step PR series) needs
to be done to keep the CIs
On Friday, 27 July 2018 at 10:48:08 UTC, ag0aep6g wrote:
On 07/27/2018 12:19 PM, Yuxuan Shui wrote:
On Friday, 27 July 2018 at 10:17:21 UTC, Yuxuan Shui wrote:
[...]
Oh no, is it just defining arrays in the is() statement,
though?
Yup.
But wait, this works:
alias C = A!(1,2,3);
static
On 07/27/2018 12:19 PM, Yuxuan Shui wrote:
On Friday, 27 July 2018 at 10:17:21 UTC, Yuxuan Shui wrote:
First, it surprised me that I can't index a struct like that. So:
struct A(T...) {
alias S = T;
alias S this;
}
alias B = A!(int, double);
B[0] x; // Actually an array
Then, it
https://issues.dlang.org/show_bug.cgi?id=19040
devinsmith0786 changed:
What|Removed |Added
CC||devinsmith0...@gmail.com
--- Comment #2
https://issues.dlang.org/show_bug.cgi?id=19120
Yuxuan Shui changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX
On Friday, July 27, 2018 03:41:29 Sameer Pradhan via Digitalmars-d wrote:
> In the end I thought I might as well dump my thoughts on the D
> forum and hear straight from the horse's (or horses')
> mouth(s)---so to speak.
It evolved out of D's member function call syntax for arrays - basically,
On Friday, 27 July 2018 at 10:17:21 UTC, Yuxuan Shui wrote:
First, it surprised me that I can't index a struct like that.
So:
struct A(T...) {
alias S = T;
alias S this;
}
alias B = A!(int, double);
B[0] x; // Actually an array
Then, it surprised me again, that I actually can index
First, it surprised me that I can't index a struct like that. So:
struct A(T...) {
alias S = T;
alias S this;
}
alias B = A!(int, double);
B[0] x; // Actually an array
Then, it surprised me again, that I actually can index it,
sometimes
static if (!is(B[0] == B[1]))
pragma(msg,
https://issues.dlang.org/show_bug.cgi?id=19120
Yuxuan Shui changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.dlang.org/show_bug.cgi?id=19121
Yuxuan Shui changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.dlang.org/show_bug.cgi?id=19121
--- Comment #1 from Yuxuan Shui ---
No wait, so there is actually no way to index a struct with a tuple alias this?
--
Hi!
Since this issue came up again here just now, I would like to
draw your attention to this particular bug.
It hinders integration with widely used build systems like
Automake, CMake, Meson and build tools like ninja/make and in
general results in very suprising results especially when
https://issues.dlang.org/show_bug.cgi?id=19121
Issue ID: 19121
Summary: Indexing a struct with a tuple alias this doesn't give
you the thing at given index
Product: D
Version: D2
Hardware: x86_64
OS: Linux
A new UDA is introduced: @manualScoped. It is valid for fields in
structs and classes, as well as variables and parameters. Fields
marked with @manualScoped are not automatically destructed on
scope end.
For instance, a function taking a struct as a @manualScoped value
will lead to a copy
https://issues.dlang.org/show_bug.cgi?id=19120
Issue ID: 19120
Summary: Cannot slice a struct with a tuple alias this
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
On Tuesday, 17 July 2018 at 09:27:26 UTC, Brian wrote:
Hello, hunt framework fix bugs version release.
Major updates:
1. Add simplify functions
2. You can use createUrl() to create link url from
module.controller.action
3. support date() / url() function for template engine
4. fix
https://issues.dlang.org/show_bug.cgi?id=19119
--- Comment #5 from Vladimir Marchevsky ---
Sorry if it's not useful, just want to point out couple of things from my
perspective as language newcomer that may hint something for you:
1) Example in ticket works when Foo::~Foo is not virtual. So
Why the memcpy?
This looks inefficient.
Is it in case the constructor throws?
Have a 'nothrow' case where it constructs directly to this?
The copy constructor must be called on an object in the initial
state,
so it cannot be called directly on this as it is already
initialized.
__dtor is
On Thu., 26 Jul. 2018, 9:35 am 12345swordy via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 26 July 2018 at 09:40:03 UTC, RazvanN wrote:
> > Hello everyone!
> >
> > As you probably know, I am working on the copy constructor DIP
> > and implementation. So far, I managed to
On Friday, 27 July 2018 at 04:56:01 UTC, Mark wrote:
Hello,
I am building a toy compiler in D, and during this I ran into a
situation.
It involves checking the header of each function, going through
the arguments, and seeing if there is any duplicate identifiers.
I have a python script that
97 matches
Mail list logo
