On Sunday, 2 July 2017 at 13:34:25 UTC, Szabo Bogdan wrote:
Any feedback is appreciated.
Thanks,
Bogdan
Hi, if you're just looking for other ideas, you might want to
look at adding capabilities like in the java hamcrest matchers.
You might also want to support regular expression matches
Congratulations to Mihails Strasuns, a.k.a. Dicebot, on the acceptance
of his DIP 1007, '"future symbol" Compiler Concept'!
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
Although the proposal recommended that the feature be implemented only
internally for DRuntime initially,
On Saturday, 8 July 2017 at 01:28:59 UTC, Walter Bright wrote:
On 7/7/2017 4:35 PM, Nicholas Wilson wrote:
It's an intrinsic in LDC. We can certainly drop the per
platform and move to a per compiler definition instead.
It's already there under:
version (DigitalMars)
I read this as
There have been two more regression fixes:
- (De)serialization of self-referential types was broken (@safe related
compile error)
- The .parentPath property of the new path types in vibe-core was broken
The release date is still scheduled for Monday.
On 7/7/2017 4:35 PM, Nicholas Wilson wrote:
It's an intrinsic in LDC. We can certainly drop the per platform and move to a
per compiler definition instead.
It's already there under:
version (DigitalMars)
On Fri, Jul 07, 2017 at 07:12:28PM -0600, Jonathan M Davis via
Digitalmars-d-announce wrote:
> On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d-
> announce wrote:
[...]
> > The implicit slice is one of what I see as D's design flaws and
> > brings up a number of problems.
On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d-
announce wrote:
> I would add a note to the "static arrays are interchangeable with
> dynamic arrays" saying that you can... and probably should
> explicitly slice them with `[]`.
>
> The implicit slice is one of what I see as
On Friday, 7 July 2017 at 22:42:08 UTC, Walter Bright wrote:
On 7/7/2017 1:33 PM, Steven Schveighoffer wrote:
Since it's an intrinsic (as confirmed by you), maybe we can
just drop the version conditions? The compiler will always
generate it, regardless of C lib, right? I'll do the PR if you
On 7/7/2017 1:33 PM, Steven Schveighoffer wrote:
Since it's an intrinsic (as confirmed by you), maybe we can just drop the
version conditions? The compiler will always generate it, regardless of C lib,
right? I'll do the PR if you agree (just want to make sure I understand your
statements
On 7/7/17 4:10 PM, Walter Bright wrote:
On 7/7/2017 12:38 PM, Steven Schveighoffer wrote:
Which would mean that the lack of alloca prototype on Windows is a
straight up bug (the fact that you can just add the declaration and it
works is pretty good proof).
It's in core.stdc.stdlib
Since
On 07-07-17 22:10, Walter Bright wrote:
On 7/7/2017 12:38 PM, Steven Schveighoffer wrote:
Which would mean that the lack of alloca prototype on Windows is a
straight up bug (the fact that you can just add the declaration and it
works is pretty good proof).
It's in core.stdc.stdlib
Only for
On 7/7/2017 12:38 PM, Steven Schveighoffer wrote:
Which would mean that the lack of alloca prototype on Windows is a straight up
bug (the fact that you can just add the declaration and it works is pretty good
proof).
It's in core.stdc.stdlib
On 7/7/2017 12:36 PM, Steven Schveighoffer wrote:
I thought alloca was an intrinsic? Which means that the compiler generates
inline code to add to the stack.
I would think it has to do this, since actually calling a function would
generate a new stack frame.
Yes and yes.
On 7/7/17 3:36 PM, Steven Schveighoffer wrote:
I thought alloca was an intrinsic? Which means that the compiler
generates inline code to add to the stack.
Which would mean that the lack of alloca prototype on Windows is a
straight up bug (the fact that you can just add the declaration and
On 7/7/17 8:59 AM, Mike Parker wrote:
This is my latest post in the GC series. I had promised the next one
would look at non-GC allocation strategies, but as it got longer and
longer I decided to break it up into two parts. This part covers stack
allocations. The next one will deal with non-GC
On Friday, 7 July 2017 at 13:48:47 UTC, Adam D. Ruppe wrote:
I would add a note to the "static arrays are interchangeable
with dynamic arrays" saying that you can... and probably should
explicitly slice them with `[]`.
The implicit slice is one of what I see as D's design flaws and
brings up
On Friday, 7 July 2017 at 12:59:44 UTC, Mike Parker wrote:
This is my latest post in the GC series. I had promised the
next one would look at non-GC allocation strategies, but as it
got longer and longer I decided to break it up into two parts.
This part covers stack allocations. The next one
This is my latest post in the GC series. I had promised the next
one would look at non-GC allocation strategies, but as it got
longer and longer I decided to break it up into two parts. This
part covers stack allocations. The next one will deal with non-GC
heap allocations.
If my luck holds
On Wednesday, 5 July 2017 at 17:59:16 UTC, Martin Nowak wrote:
Second beta for the 2.075.0 release.
Comes with a couple of more fixes for dmd, phobos, and dub:
https://github.com/dlang/dmd/compare/v2.075.0-b1...v2.075.0-b2
https://github.com/dlang/phobos/compare/v2.075.0-b1...v2.075.0-b2
On Monday, 3 July 2017 at 12:39:16 UTC, Nordlöw wrote:
Nice. Are there any plans on adding any (limited) kind of
auto-completion of UFCS-calls?
I think that you have the answer
https://github.com/dlang-community/DCD/issues/13.
Now that i read my proposal again i have to say that i don't
20 matches
Mail list logo
