On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote:
because it tends to become very difficult to get right in all
cases and results in situations where the programmer is forced
to do something in order to make the compiler shut up
Well, doesn't this post show exactly this problem,
On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel
wrote:
But in D, everything is your friend - you don't get to manage
You want to be taken seriously and yet you repeat false
statements over and over again.
There is absol
On Sunday, 20 May 2018 at 10:56:27 UTC, Yuxuan Shui wrote:
On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote:
because it tends to become very difficult to get right in all
cases and results in situations where the programmer is forced
to do something in order to make the compiler s
On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
The return type for range-oriented functions in std.algorithm
is usually not terribly useful.
So the first question that comes to my mind are what are the
'rules' of the output. Which is really what typing is. It's a
series of rule
On Sunday, May 20, 2018 10:56:27 Yuxuan Shui via Digitalmars-d wrote:
> On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote:
> > because it tends to become very difficult to get right in all
> > cases and results in situations where the programmer is forced
> > to do something in order t
On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
D is very hard to make an IDE for that would actually tell you
what type the return value is.
This might sound a little hard, but that's probably a fundamental
failure of the D language and explains some of the poor tooling
around
On Sunday, 20 May 2018 at 14:39:28 UTC, Jonathan M Davis wrote:
Well, constructors are one of the few places that the compiler
attempts flow analysis for stuff other than optimization,
because it pretty much has to in order to do what the language
needs. And no, it's not very sophisticated abou
On Sunday, May 20, 2018 14:33:16 I love Ice Cream via Digitalmars-d wrote:
> On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
> > The return type for range-oriented functions in std.algorithm
> > is usually not terribly useful.
>
> So the first question that comes to my mind are what a
On Saturday, 19 May 2018 at 15:09:38 UTC, Joakim wrote:
D does well, comes in second on Mac/Win/linux:
https://github.com/frol/completely-unscientific-benchmarks
https://www.reddit.com/r/programming/comments/8jbfa7/naive_benchmark_treap_implementation_of_c_rust/
The results in these tests are
load and save are not working, an example is always compiled in.
No code in the input box still shows examples code in the
disassembly.
On Friday, 21 September 2012 at 03:46:12 UTC, Andrei Alexandrescu
wrote:
I've met Matt Goldbolt, the author of the GCC Explorer at
http://gcc.godbolt.org - a very handy online disassembler for
GCC.
We got to talk a bit about D and he hacked together support for
D by using gdc. Take a look at
On Sunday, 20 May 2018 at 14:35:21 UTC, I love Ice Cream wrote:
On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
D is very hard to make an IDE for that would actually tell you
what type the return value is.
This might sound a little hard, but that's probably a
fundamental failure
On 5/20/2018 9:47 AM, IntegratedDimensions wrote:
load and save are not working, an example is always compiled in. No code in the
input box still shows examples code in the disassembly.
Please post bug reports to https://issues.dlang.org/
I've started digging at some surfac-ey extern(C++) issues.
First up, I desperately want a document that describes D's precise
construction/destruction rules; there are a bunch of generated
functions, they get called, in what order, and under what conditions?
Construction:
What is the order of o
On 20 May 2018 at 12:28, Manu wrote:
>
> [...]
Then... next up, extern(C++) classes need to place __xdtor in the
vtable (posix uses 2 slots).
We need the vtable to match naturally, without advising people to add
a dummy method.
I also have a hack in progress to support `final ~this()` in
extern(
On 5/20/2018 12:28 PM, Manu wrote:
I've started digging at some surfac-ey extern(C++) issues.
I've improved the definition of how construction works, such as when the .init
happens, in the spec.
https://dlang.org/spec/class.html#constructors
> Is __xdtor **always** present?
No. If it's POD
On 5/20/2018 12:28 PM, Manu wrote:
Is re-initialisation to 'init' part of destruction,
No.
or is it a
separate post-process? (I feel it's a post-process)
Yes, and only for delete.
Code for context:
https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d
Something struck me at DConf. I was watching the dxml talk and
hearing about all these things that weren't being implemented for
one reason or another. And I was thinking, "But
On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
Code for context:
https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d
This looks good. One small caveat:
alias DocumentType = SomeDocument!(ObjectVersion._1_0,
ObjectEncoding.UTF8);
alias Docu
On 20 May 2018 at 17:14, Walter Bright via Digitalmars-d
wrote:
> On 5/20/2018 12:28 PM, Manu wrote:
>>
>>Is re-initialisation to 'init' part of destruction,
>
>
> No.
>
>> or is it a
>> separate post-process? (I feel it's a post-process)
>
>
> Yes, and only for delete.
destroy() also seems t
I don't really like that SomeObject() will be instantiated a crap load
of times for every possible combination and order of options that a
user might want to supply. How do you control the bloat in a way that
people won't mess up frequently?
On 20 May 2018 at 17:58, Neia Neutuladh via Digitalmars-
auto has its uses, but it's wildly overused, especially in library code
and documentation, and really, really, *really* much so in documentation
examples.
On 05/01/2018 06:09 AM, Craig Dillabaugh via Digitalmars-d wrote:
On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
I'll freely admi
On Sunday, 20 May 2018 at 11:19:01 UTC, Dave Jones wrote:
On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel
wrote:
But in D, everything is your friend - you don't get to manage
You want to be taken seriously and yet you repe
On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
But the functions, they're a bit trickier. So I made a new
trait in Binderoo's traits module called ExtractTupleOf. The
template prototype is the following:
template ExtractTupleOf( alias TestTemplate, Symbols... )
That first parameter is t
This CI situation with the DMD/druntime repos is not okay.
It takes ages... **hours** sometimes, for CI to complete.
It's all this 'auto-tester' one, which seems to lock up on the last few tests.
This makes DMD is a rather unenjoyable project to contribute to.
I had a sudden burst of inspiration,
On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote:
I wouldn't consider putting classes into own modules a
workaround. In my opinion it's more or less the solution.
I'll add your solution into my article - but, I'm not sure it
really addresses my problem statement.
The Problem Statement
On Monday, 21 May 2018 at 01:53:20 UTC, Manu wrote:
I don't really like that SomeObject() will be instantiated a
crap load of times for every possible combination and order of
options that a user might want to supply. How do you control
the bloat in a way that people won't mess up frequently?
27 matches
Mail list logo
