https://issues.dlang.org/show_bug.cgi?id=18996
Basile B. changed:
What|Removed |Added
Component|phobos |druntime
--- Comment #4 from Basile B. ---
https://issues.dlang.org/show_bug.cgi?id=18996
Basile B. changed:
What|Removed |Added
CC||b2.t...@gmx.com
Hardware|x86_64
https://issues.dlang.org/show_bug.cgi?id=18996
--- Comment #2 from Paul Crane ---
After even more testing it looks like only Array's with strings are causing
this issue:
struct Test
{
string value;
}
void main(string[] arguments)
{
//Cause SIGILL
Array!string str;
https://issues.dlang.org/show_bug.cgi?id=18996
--- Comment #1 from Paul Crane ---
Actually, all it takes is:
import std.container;
void main(string[] arguments)
{
Array!string str;
str.insert("hello");
}
Up to 2.078.1: Success and no output
Since 2.079.0: Failure with
https://issues.dlang.org/show_bug.cgi?id=19000
Benjamin Schaaf changed:
What|Removed |Added
CC||ben.sch...@gmail.com
--- Comment #1 from
On Saturday, 16 June 2018 at 06:43:25 UTC, Meta wrote:
On Saturday, 16 June 2018 at 00:24:42 UTC, DigitalDesigns wrote:
space is ignored! Seems like a bug std . traits . std . string
is valid?
Like most C-family languages, D is a freeform language[1].
Funnily enough, I don't think this is
https://issues.dlang.org/show_bug.cgi?id=18984
--- Comment #2 from Manu ---
Do you have any feel for the difficulty of this patch?
Is it just an if somewhere to detect if RVO and point the debuginfo at a
different location?
It'd be really good to get a fix in 2.081 if possible, since the guys
On Sunday, 17 June 2018 at 10:58:29 UTC, Cauterite wrote:
Is there a reason scope(success) needs to set up for exception
handling?
Or is this a bug / potential enhancement ?
If you had no exception handling in place, you'd need to
duplicate code in the output. For instance:
void foo()
{
On Sunday, 17 June 2018 at 20:03:09 UTC, aliak wrote:
On Sunday, 17 June 2018 at 02:44:38 UTC, Heromyth wrote:
[...]
I think this bolts.isManifestAssignable [1] will get you
partially there. The place where it'll fail though is a static
immutable (since they are assignable to manifest
https://issues.dlang.org/show_bug.cgi?id=18966
Manu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Monday, 18 June 2018 at 02:31:25 UTC, Mike Franklin wrote:
Unfortunately the code gen is quite a bit worse:
Scratch that. If compiling with -O it seems to do the right
thing.
Mike
On Sunday, 17 June 2018 at 17:00:00 UTC, David Nadlinger wrote:
On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
https://github.com/JinShil/memcpyD
[…]
Feedback, advise, and pull requests to improve the
implementation are most welcome.
The memcpyD implementation is buggy;
On Sunday, 17 June 2018 at 17:48:21 UTC, FromAnotherPlanet wrote:
On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
The only case where D loses out is compared to { get; private
set; }.
That's a pretty big thing to give up. That allows for pretty
valuable control over
On Sunday, 17 June 2018 at 22:55:57 UTC, Walter Bright wrote:
On 6/15/2018 11:08 PM, DigitalDesigns wrote:
When an identifier starts with __, allMembers does not return
it. This is very bad behavior! It can silently create huge
problems if the programmer is not aware of the bug.
It's not a
emeralD is a command-line tool for template files that can be
used to generate code files, configurations etc.
It's a very useful tool for generating files that you'd normally
have to create by hand.
The idea for emeralD was not actually by me, but by Moogly (I
don't know what he goes by in
On 6/15/2018 11:08 PM, DigitalDesigns wrote:
When an identifier starts with __, allMembers does not return it. This is very
bad behavior! It can silently create huge problems if the programmer is not
aware of the bug.
It's not a bug, it's quite deliberate:
On Sunday, 17 June 2018 at 02:29:12 UTC, Adam D. Ruppe wrote:
On Saturday, 16 June 2018 at 08:32:38 UTC, DigitalDesigns wrote:
I need to get the protected and private members for
serialization.
This breaks encapsulation.
A better design would be to have a class know how to serialize
itself
https://issues.dlang.org/show_bug.cgi?id=18982
--- Comment #6 from Manu ---
Haha, nice solution :P
--
I did not mention it in the README, but the tred filter used in
https://code.dlang.org/packages/depend complains about cyclic
dependencies.
I am currently working on a branch, where the transitive
reduction and the corresponding warnings are built in.
While this tool is for D only, it also
https://issues.dlang.org/show_bug.cgi?id=18026
--- Comment #14 from ag0aep6g ---
Removed Phobos from the test case from comment 10, and made sure that it fails
reliably (for me) by raising the number of enum members again:
enum Type
{
On Sunday, 17 June 2018 at 13:50:31 UTC, Seb wrote:
On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote:
What are your thoughts? Do you agree with this coding pattern?
It would even be better if map can recognize tuples and thus
allows to simply use a lambda functions with two parameters,
On Sunday, 17 June 2018 at 02:44:38 UTC, Heromyth wrote:
Here is a struct named S:
struct S
{
enum X = 10;
enum Y
{
i = 10
}
enum Z = "str";
struct S {}
class C {}
static int sx = 0;
__gshared int gx = 0;
The following
unittest
{
import std.datetime.date : Date;
Date date;
import core.internal.hash : hashOf;
auto hash = date.hashOf;
}
errors (with DMD v2.081.0-beta.1) as
/usr/include/dmd/druntime/import/core/internal/convert.d(619,101): Error:
template
On Sunday, 17 June 2018 at 17:00:00 UTC, David Nadlinger wrote:
core.simd.loadUnaligned instead
Ah, well… https://issues.dlang.org/show_bug.cgi?id=19001
— David
https://issues.dlang.org/show_bug.cgi?id=19001
Issue ID: 19001
Summary: core.simd.{load, store}Unaligned arguments presume
alignment
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
The only case where D loses out is compared to { get; private
set; }.
That's a pretty big thing to give up. That allows for pretty
valuable control over visibility of encapsulated properties.
On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
https://github.com/JinShil/memcpyD
[…]
Feedback, advise, and pull requests to improve the
implementation are most welcome.
The memcpyD implementation is buggy; it assumes that all
arguments are aligned to their size. This
https://issues.dlang.org/show_bug.cgi?id=18982
Rainer Schuetze changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.dlang.org/show_bug.cgi?id=18978
Rainer Schuetze changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:
For someone coming from a C# background there is some seemingly
simple syntactic sugar missing from D.
* The null conditional operator `?.`
Null-safe dereference operator, I think it's called?
Hrm, my first impulse was in favor.
On Monday, 11 June 2018 at 03:34:59 UTC, Basile B. wrote:
- default linux:
https://github.com/gcc-mirror/gcc/blob/master/libgcc/memcpy.c
To see what is executed when you call memcpy() on a regular
GNU/Linux distro, you'd want to have a look at glibc instead. For
example, the AVX2 and AVX512
On Monday, 11 June 2018 at 08:02:42 UTC, Walter Bright wrote:
On 6/10/2018 9:44 PM, Patrick Schluter wrote:
See what Agner Fog has to say about it:
Thanks. Agner Fog gets the last word on this topic!
Well, Agner is rarely wrong indeed, but there is a limit to how
much material a single
On Sunday, 17 June 2018 at 12:24:35 UTC, FromAnotherPlanet wrote:
What's the differences in the approaches between SOLID and
component programming? Are they orthogonal? Or can they be used
together?
It looks like they have some overlap, but are not the same. SOLID
seems focused on OOP,
On Sunday, 17 June 2018 at 12:23:55 UTC, Steven Schveighoffer
wrote:
On 6/17/18 7:07 AM, Vijay Nayar wrote:
This code breaks with the following error:
void main()
{
import std.range;
int[] vals = [];
vals.put(3);
}
/src/phobos/std/range/primitives.d(2328): Attempting to fetch
On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote:
What are your thoughts? Do you agree with this coding pattern?
It would even be better if map can recognize tuples and thus
allows to simply use a lambda functions with two parameters, but
in the past with a few exceptions there hasn't
On Sunday, 17 June 2018 at 10:58:29 UTC, Cauterite wrote:
---
// main.d
void main() {
scope(success) {}
}
dmd -betterC main.d
Error: Cannot use try-catch statements with -betterC
---
You can see what the compiler is doing at
https://run.dlang.io/is/5BZOQV and clicking on the
On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote:
snip]
What are your thoughts? Do you agree with this coding pattern?
I like it.
On 6/17/18 8:24 AM, Timoses wrote:
On Sunday, 17 June 2018 at 10:58:29 UTC, Cauterite wrote:
Hello,
I'm not sure whether I'm missing something obvious here, but is there
a reason for scope(success) being lowered to a try-catch statement?
I would have expected only scope(exit) and
On Sunday, 17 June 2018 at 12:10:33 UTC, Nicholas Wilson wrote:
I suspect scope(success) is lowered because scope(exit) and
scope(failure)
are, and that would result in a simpler (compiler)
implementation of it.
does adding nothrow to main fix it? For dcompute I specifically
allow
What's the differences in the approaches between SOLID and
component programming? Are they orthogonal? Or can they be used
together?
On 6/17/18 7:07 AM, Vijay Nayar wrote:
This code breaks with the following error:
void main()
{
import std.range;
int[] vals = [];
vals.put(3);
}
/src/phobos/std/range/primitives.d(2328): Attempting to fetch the front
of an empty array of int
The following code has no error:
On 6/17/18 6:58 AM, Cauterite wrote:
Hello,
I'm not sure whether I'm missing something obvious here, but is there a
reason for scope(success) being lowered to a try-catch statement?
I would have expected only scope(exit) and scope(failure) to actually
interact with exception handling, while
On Sunday, 17 June 2018 at 10:58:29 UTC, Cauterite wrote:
Hello,
I'm not sure whether I'm missing something obvious here, but is
there a reason for scope(success) being lowered to a try-catch
statement?
I would have expected only scope(exit) and scope(failure) to
actually interact with
On 6/16/18 6:23 PM, Jonathan M Davis wrote:
I kind of wish that the forum software discouraged against necro-ing threads
like this, since they're easy for many of us to miss, and once someone
replies to them and brings them to the front of the list in the forum
software, folks tends to reply as
On Sunday, 17 June 2018 at 10:58:29 UTC, Cauterite wrote:
Hello,
I'm not sure whether I'm missing something obvious here, but is
there a reason for scope(success) being lowered to a try-catch
statement?
I would have expected only scope(exit) and scope(failure) to
actually interact with
On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov wrote:
Is it possible to introduce a new parameter/flag to the
compiler, to force all functions be @safe by default on a
per-module basis?
Forgive me if you're already aware of this, but to ensure your
entire program is `@safe`
On 6/16/18 4:27 PM, Jacob Shtokolov wrote:
On Saturday, 16 June 2018 at 18:47:10 UTC, Steven Schveighoffer wrote:
I would just caution that this does not affect member functions, only
module-level functions. You have to repeat the @safe: inside any
structs or classes as well.
Just tried that
This code breaks with the following error:
void main()
{
import std.range;
int[] vals = [];
vals.put(3);
}
/src/phobos/std/range/primitives.d(2328): Attempting to fetch the
front of an empty array of int
The following code has no error:
void main()
{
import
https://github.com/vnayar/detectcycles
I made a small configurable tool to detect software source
dependency cycles that is configurable to use for most languages.
By default, C++, Java, and D are supported, but add new languages
is as simple as adding a few lines to JSON configuation file.
https://issues.dlang.org/show_bug.cgi?id=18994
--- Comment #1 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/dmd
https://github.com/dlang/dmd/commit/42f7252a19640f276e046e8fd264d4484eb82619
fix issue 18994 - Use noncopyable variable in foreach loop
https://issues.dlang.org/show_bug.cgi?id=18994
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Hello,
I'm not sure whether I'm missing something obvious here, but is
there a reason for scope(success) being lowered to a try-catch
statement?
I would have expected only scope(exit) and scope(failure) to
actually interact with exception handling, while scope(success)
simply places code on
On Saturday, 16 June 2018 at 19:20:30 UTC, FromAnotherPlanet
wrote:
- Interface segregation principal: Essentially breaking the
program up into smaller interfaces. Sometimes only consistent
of one or two methods/properties (can feed into 'S' of SOLID
quite nicely).
- Dependency inversion
On Sunday, 17 June 2018 at 02:25:59 UTC, Adam D. Ruppe wrote:
On Sunday, 17 June 2018 at 01:02:17 UTC, DigitalDesigns wrote:
If this was a sane language constraint then any identifiers
starting with __ that were not reserved would at least give a
warning but particularly give an error! Not
On Sunday, 17 June 2018 at 04:32:29 UTC, Jonathan M Davis wrote:
On Sunday, June 17, 2018 02:44:38 Heromyth via
Digitalmars-d-learn wrote:
Here is a struct named S:
struct S
{
enum X = 10;
enum Y
{
i = 10
}
enum Z = "str";
struct S {}
class C {}
static int sx = 0;
https://issues.dlang.org/show_bug.cgi?id=18993
Basile B. changed:
What|Removed |Added
Keywords||pull
--- Comment #3 from Basile B. ---
Pull
https://issues.dlang.org/show_bug.cgi?id=18998
Seb changed:
What|Removed |Added
Keywords||bootcamp
CC|
On Sunday, 17 June 2018 at 05:20:51 UTC, Manu wrote:
The biggest highlight in this release for C++ users like myself
is a
huge amount of work relating to extern(C++). I think this is the
biggest step forward since it was introduced in 2012.
Mixed-language class hierarchies are now supported,
58 matches
Mail list logo
