On Wednesday, 24 May 2017 at 15:49:58 UTC, Steven Schveighoffer
wrote:
On 5/23/17 3:47 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/phobos/pull/5421
Looking forward to more in the same vein, please contribute!
We have 25
left in phobos and 12 in druntime. A big one will be making
t
On Wednesday, 24 May 2017 at 20:15:37 UTC, Vittorio Romeo wrote:
I've created a very WIP draft here:
https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md
If you're interested in contributing, please let me know and
I'll add you as a collaborator.
Yep, I've made a small PR to make m
On Thursday, 25 May 2017 at 00:34:45 UTC, MysticZach wrote:
I've created a very WIP draft here:
https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md
If you're interested in contributing, please let me know and
I'll add you as a collaborator.
As a matter of procedure, you don't want
On Thursday, 25 May 2017 at 01:18:22 UTC, Mike Parker wrote:
label:
if (self.bored) goto disclaimer;
We're well aware. The file name is not indicative of anything.
The README outlines the procedure for DIP submission, including
the format of the filename. The concern is that if you include
On Thursday, 25 May 2017 at 03:10:04 UTC, Adam D. Ruppe wrote:
"Currently FunctionLiterals that capture their outer context
(i.e. closures/delegates) require an allocation and the garbage
collector. "
Not necessarily true, make sure you actually mention `scope
delegate` and `alias` params
On Thursday, 25 May 2017 at 03:42:11 UTC, Adam D. Ruppe wrote:
On Thursday, 25 May 2017 at 03:30:38 UTC, Stanislav Blinov
wrote:
Captures, if any, should be explicit. That is all :)
The current behavior is fine in most cases. The explicit
by-value capture handles the remaining cases.
In my
On Thursday, 25 May 2017 at 01:17:41 UTC, Timothee Cour wrote:
thanks; i think docs for this should still make that clear.
How about adding memoizeShared for shared variables?
There definitely are use cases for this.
Perhaps we should first actually properly document and implement
what share
On Thursday, 25 May 2017 at 04:53:14 UTC, Mike Parker wrote:
On Thursday, 25 May 2017 at 03:14:14 UTC, Stanislav Blinov
wrote:
Mike, I've read that README several times over. Yes, a mistake
was made, a number self-assigned. Yes, that is not how it's
done. Yes, we know. Yes. Than
On Thursday, 25 May 2017 at 10:41:23 UTC, Andrei Alexandrescu
wrote:
On Thursday, 25 May 2017 at 03:51:05 UTC, Stanislav Blinov
wrote:
On Thursday, 25 May 2017 at 01:17:41 UTC, Timothee Cour wrote:
thanks; i think docs for this should still make that clear.
How about adding memoizeShared for
On Monday, 22 May 2017 at 17:05:06 UTC, Stanislav Blinov wrote:
Considering that the core runtime component - the GC - is the
one that usually handles finalization, it follows that *GC
collection can never be @safe*. And since collection only
happens during allocation, it follows that
On Friday, 26 May 2017 at 14:38:41 UTC, Steven Schveighoffer
wrote:
Here is my story:
http://www.schveiguy.com/blog/2017/05/how-to-report-a-bug-to-microsoft/
-Steve
- I am here for the job interview.
- But you are two weeks late!
- Thank you for contacting our support department...
- You're h
On Friday, 26 May 2017 at 17:08:40 UTC, Igor Shirkalin wrote:
On Monday, 22 May 2017 at 17:05:06 UTC, Stanislav Blinov wrote:
I'd like to hear what you guys think about this issue:
https://issues.dlang.org/show_bug.cgi?id=15246
[...]
If your destructor is not @safe and @nogc, why n
On Friday, 26 May 2017 at 17:32:38 UTC, Igor Shirkalin wrote:
On Friday, 26 May 2017 at 17:17:39 UTC, Stanislav Blinov wrote:
Destructors of derived classes are called implicitly on
finalization. The net effect is that such finalization adopts
the weakest set of attributes among all the
On Friday, 26 May 2017 at 18:58:46 UTC, Igor Shirkalin wrote:
First, why 'oblivious' function does not free Malicious object
(no matter GC or not GC).
It actually does matter. It doesn't manually release the
resources precisely because it relies on the GC. I've made it
overly explicit, but i
On Monday, 22 May 2017 at 17:05:06 UTC, Stanislav Blinov wrote:
I'd like to hear what you guys think about this issue:
https://issues.dlang.org/show_bug.cgi?id=15246
Any thoughts?
By the absence of replies from those who (I think) should care I
conclude that either:
1. I
On Saturday, 27 May 2017 at 14:12:09 UTC, Ola Fosheim Grøstad
wrote:
I wonder, what would break if all the features of class was
merged into struct?
Imagine that:
class Something ... { ... }
is lowered into:
struct _class_Something ... { ... }
alias Something = MagicClassRef!_cla
On Saturday, 27 May 2017 at 13:32:57 UTC, Adam D. Ruppe wrote:
On Saturday, 27 May 2017 at 10:11:38 UTC, Stanislav Blinov
wrote:
3. Nobody actually cares.
That's me. I think the @attribute mess is completely broken and
mostly just ignore it.
Hm. That's a strategy, perhaps I sho
On Saturday, 27 May 2017 at 16:23:33 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 16:04:42 UTC, Stanislav Blinov
wrote:
It's not "a little bit", it's ABI down the drain, along with a
good part of runtime. And we'd lose interfaces and extern(C++).
Why w
On Saturday, 27 May 2017 at 16:37:04 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 16:31:32 UTC, Stanislav Blinov
wrote:
There's a lot more difference in D. Classes in D are fat
memory chunks storing pointers to ClassInfo (inc. vtable),
So are classes with virtual functions
On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 16:52:17 UTC, Stanislav Blinov
wrote:
But structs in D have none of that.
Neither does C++ if you don't add a virtual function to it, so
it would be the same.
My question isn't wheth
On Saturday, 27 May 2017 at 17:19:48 UTC, Moritz Maxeiner wrote:
On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad
wrote:
The class reference type should be fixable with a rewrite into
templated smart pointers, so no need for big changes there, I
think.
Smart pointers impose a
On Saturday, 27 May 2017 at 17:30:49 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 17:22:02 UTC, Stanislav Blinov
wrote:
But they are incompatible precisely because structs "don't
have it". Inheritance for one. Reference semantics for
another. A class reference
On Saturday, 27 May 2017 at 18:13:52 UTC, Ola Fosheim Grøstad
wrote:
Or did we leave behind your original question?
No. I am talking about language semantics. Are the semantics
for class and struct conflicting or can they be merged?
That is the question.
I am talking about the language, a
On Saturday, 27 May 2017 at 18:44:42 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 18:44:03 UTC, Stanislav Blinov
wrote:
On Saturday, 27 May 2017 at 18:13:52 UTC, Ola Fosheim Grøstad
wrote:
Or did we leave behind your original question?
No. I am talking about language
On Sunday, 28 May 2017 at 17:34:30 UTC, Nerve wrote:
--- refcounted ---
The allocation method used by refcounted can be overloaded...
1. Then the deallocation has to also be overloaded.
2. This introduces tight coupling between a type and its
allocator, preventing the programmer from reusi
On Sunday, 28 May 2017 at 22:03:48 UTC, Stefan Koch wrote:
On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:
Imagine you wrote a function
void foo(ref int a) {
if (std.random.uniform(0, 10) == 0)
a = 0;
// Actual code doing something
}
[...]
Syntax wise we could force you to
On Monday, 29 May 2017 at 07:39:40 UTC, Dukc wrote:
But what would be worth a consideration, is that perhaps one
should be allowed to pass rvalues as reference with something
like this? According to TDPL, ref arguments do not take rvalues
to prevent bugs where you accidently copy something bef
On Monday, 29 May 2017 at 08:41:05 UTC, Jonathan M Davis wrote:
I probably didn't say it very well.
With C++, if you have const T&, it will accept both lvalues and
rvalues. A number of folks (particularly those writing games)
want an equivalent to that in D where they can then pass both
lval
On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote:
On Monday, May 29, 2017 17:19:27 Stanislav Blinov via
Digitalmars-d wrote:
`in` is `const scope`
Walter recently changed is that in is now just const, because
scope was not properly implemented previously, and folks were
using
On Monday, 29 May 2017 at 20:31:18 UTC, Jonathan M Davis wrote:
On Monday, May 29, 2017 20:00:12 Stanislav Blinov via
Digitalmars-d wrote:
On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote:
> On Monday, May 29, 2017 17:19:27 Stanislav Blinov via
>
> Digitalmars-d wrote:
&
On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote:
That definition currently there is more precise than the
definition on that page has been historically...
Apparently, it is not. Do you have a reference to Walter's change
regarding `in` becoming just `const`? Because a change l
On Tuesday, 30 May 2017 at 09:55:14 UTC, Petar Kirov [ZombineDev]
wrote:
Unfortunately, `in` was never implemented as `scope const`. I
think it was only when Walter started working actively on
scope that he found out that it's too late to change this -
https://github.com/dlang/dmd/pull/5898. H
On Tuesday, 30 May 2017 at 15:59:04 UTC, Andrei Alexandrescu
wrote:
On 05/30/2017 05:48 AM, Petar Kirov [ZombineDev] wrote:
On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov
wrote:
On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis
wrote:
That definition currently there is
On Tuesday, 30 May 2017 at 16:19:26 UTC, Andrei Alexandrescu
wrote:
Apparently, it is not. Do you have a reference to Walter's
change regarding `in` becoming just `const`? ...
Unfortunately, `in` was never implemented as `scope const`.
Why would it need to be `const`? Thanks! -- Andrei
Wha
On Thursday, 1 June 2017 at 14:10:21 UTC, John Colvin wrote:
I would be interested to see ideas of how to implement some
sort of logical sandboxing in D. Perhaps if one calls a
strongly pure @safe function, there is no way it can mess up
shared state,
Oh yes, there is a way:
http://forum.dl
On Thursday, 1 June 2017 at 18:40:28 UTC, Walter Bright wrote:
On 6/1/2017 7:21 AM, Stanislav Blinov wrote:
Oh yes, there is a way:
http://forum.dlang.org/post/psdamamjecdwfeiuv...@forum.dlang.org
Please post bug reports to bugzilla. Posting them only on the
n.g. pretty much ensures they
On Friday, 2 June 2017 at 18:43:32 UTC, Andrei Alexandrescu wrote:
A clean slate is alluring, and there are several things that
can be done differently in Phobos, as there are in any project
that's been around for a while. It may, however, be difficult
to find enough people able and willing to
On Saturday, 3 June 2017 at 19:12:46 UTC, Steven Schveighoffer
wrote:
On Saturday, 3 June 2017 at 17:32:41 UTC, Andrei Alexandrescu
wrote:
On 06/03/2017 01:03 PM, Russel Winder via Digitalmars-d wrote:
Björn Fahller has done compile time sort in C++17 here
http://playfulpr
ogramming.blogspot.c
On Saturday, 3 June 2017 at 20:18:59 UTC, Basile B. wrote:
On Saturday, 3 June 2017 at 18:45:56 UTC, Jacob Carlborg wrote:
On 2017-06-03 20:31, Russel Winder via Digitalmars-d wrote:
But is this sort guaranteed to happen at compile time rather
than
runtime?
Yes. It's the context that decide
On Saturday, 3 June 2017 at 21:04:16 UTC, ag0aep6g wrote:
On 06/03/2017 10:29 PM, Stanislav Blinov wrote:
Meep. Wrong :)
Static initializers for static variables and constants are
evaluated at compile time, initializing them with runtime
values is a compile-time error.
Meep. Meep. I
Suppose I need to allocate several dynamic arrays of different
types and/or sizes. An obvious choice is to do just that: perform
N allocations.
But given that I know all the sizes, and also am pretty sure that
each of the arrays will have the same lifespan, why would I do N
allocations when I c
On Sunday, 4 June 2017 at 05:38:24 UTC, H. S. Teoh wrote:
And if you need a particular functionality both at compile-time
and during runtime, there's no need to write it twice in two
different sublanguages. You just write one function once, and
call it from both CTFE and at runtime. It Just Wo
On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote:
I'd like to publish it tomorrow (Monday), so I've put the draft
in a gist [2] and I'm looking to get anyone who's willing to
read it and let me know here if I've made any errors.
https://gist.github.com/mdparker/c674888dea1e0ead0c6a8
On Sunday, 4 June 2017 at 09:38:45 UTC, ag0aep6g wrote:
Should this work, and if not, why?
As far as I can tell, the `addRange` call works correctly, but
maybe too well in a sense. It keeps the `new`ed `C`s alive as
long as `arrays3.Cs` has pointers to them. And `arrays3.Cs` has
those point
On Monday, 5 June 2017 at 13:11:25 UTC, Steven Schveighoffer
wrote:
adding a range marks it as having pointers to scan, AND stores
a reference to that array, so it won't be GC collected (nor
will anything it points to). The intention is for it to be used
on non-GC memory, like C malloc'd memo
On Tuesday, 6 June 2017 at 09:57:31 UTC, Steven Schveighoffer
wrote:
Note that p[0 .. sz] is treated as an opaque range of memory
assumed to be suitably managed by the caller. In particular,
if p points into a GC-managed memory block, addRange does not
mark this block as live.
Is that parag
On Tuesday, 6 June 2017 at 09:57:31 UTC, Steven Schveighoffer
wrote:
No, 2 allocations instead of N.
Oh, I misunderstood you. You mean two blocks total, for scanned
and non-scanned data. This could indeed work for cases when more
than two arrays are needed. Still, it's one extra allocation.
On Tuesday, 6 June 2017 at 12:07:28 UTC, Steven Schveighoffer
wrote:
On 6/6/17 6:36 AM, Stanislav Blinov wrote:
On Tuesday, 6 June 2017 at 09:57:31 UTC, Steven Schveighoffer
wrote:
No, 2 allocations instead of N.
Oh, I misunderstood you. You mean two blocks total, for
scanned and
non
On Tuesday, 6 June 2017 at 13:05:51 UTC, Steven Schveighoffer
wrote:
Actually, separate blocks might be a decent choice: there's
another
problem with sharing blocks for different data in that
finalizers can't
be run. So such a function would either not support types with
finalizers at all, or
On Tuesday, 6 June 2017 at 13:29:32 UTC, Stanislav Blinov wrote:
Structs, on the other hand, are another matter. Although, even
creating a block with BlkAttr.FINALIZE *and* passing the struct
typeinfo to GC.malloc() doesn't seem to compel it to run the
struct dtors on collect, which is
On Wednesday, 7 June 2017 at 03:06:34 UTC, Ali Çehreli wrote:
On 06/06/2017 06:09 PM, Steven Schveighoffer wrote:
> But it is pretty well known that enum'ing an array can have
it allocate
> wherever it is used.
One of the most effective examples is comparing .ptr with
(seemingly) itself:
voi
On Wednesday, 7 June 2017 at 23:57:44 UTC, Mike B Johnson wrote:
Or will simply setting "alias string = wstring;" at the top of
my program end up having the entire program, regardless of what
it is, use wstring's instead of strings?
It doesn't work that way and it can't work that way: you'd n
On Thursday, 8 June 2017 at 14:13:53 UTC, Steven Schveighoffer
wrote:
void foo(Mutex m, Data d) pure
{
synchronized(m)
{
// ... manipulate d
} // no guarantee m gets unlocked
}
-Steve
Isn't synchronized(m) not nothrow?
On Sunday, 11 June 2017 at 16:28:23 UTC, Timon Gehr wrote:
I'd prefer
bool msg(bool constraint, string message){ return constraint; }
This does not require the compiler to dive into a branch it
wouldn't consider otherwise, and the pairing of constraint to
message is less ad-hoc.
Where were
On Sunday, 11 June 2017 at 19:06:48 UTC, Andrei Alexandrescu
wrote:
I tried to eliminate the static shared ~this as follows:
https://github.com/dlang/phobos/pull/5470/commits/a4b2323f035b663727349d390719509d0e3247ba
However, unittesting fails at src/core/thread.d(2042). I
suspect it's because
On Monday, 12 June 2017 at 14:21:29 UTC, Andrei Alexandrescu
wrote:
On 06/12/2017 12:13 AM, Stanislav Blinov wrote:
On Sunday, 11 June 2017 at 19:06:48 UTC, Andrei Alexandrescu
wrote:
I tried to eliminate the static shared ~this as follows:
https://github.com/dlang/phobos/pull/5470/commits
Shachar, as I don't see a better place of discussing that DIP at
the moment, I'll pour some observations and thoughts in here if
you don't mind, will add some comments on GitHub later.
As I see it right now, it's a case of over-engineering of a quite
simple concept.
1. A new function, called _
On Wednesday, 3 October 2018 at 13:56:29 UTC, Stanislav Blinov
wrote:
Aendment, this should of course be:
this(Tracker oldLocation) {
localCounter = oldLocation.locaclCounter;
counter = oldLocation.counter;
if( counter is &oldLocation.localCou
On Wednesday, 3 October 2018 at 14:07:58 UTC, Shachar Shemesh
wrote:
On 03/10/18 16:56, Stanislav Blinov wrote:
struct S {
this(S rhs);
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
Now I see why sometimes your posts are greeted with hostility.
And t
On Wednesday, 3 October 2018 at 14:07:58 UTC, Shachar Shemesh
wrote:
If you read the DIP, you will notice that the *address* in
which the old instance resides is quite important...
Allow me to further illustrate with something that can be written
in D today:
import std.stdio;
struct Track
On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh
wrote:
On 03/10/18 17:29, Stanislav Blinov wrote:
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
Now I see why sometimes your posts are greeted with hostility.
Yes. I am actually sorry about t
On Wednesday, 3 October 2018 at 17:43:08 UTC, Stanislav Blinov
wrote:
But IMHO, it's something that should be fixed by not making
these facilities built into the language.
s/not//
On Wednesday, 3 October 2018 at 08:21:38 UTC, Manu wrote:
Okay, so copy elision is working... but moves otherwise are
not? That's still not what we've been peddling all these years.
A whole lot of design surface area is dedicated to implicit
move semantics... and they don't work? What does it
On Wednesday, 3 October 2018 at 18:38:50 UTC, Manu wrote:
On Wed, Oct 3, 2018 at 7:00 AM Stanislav Blinov via
Digitalmars-d wrote:
Any function in D that has a signature of the form
ReturnType foo(Type x);
in C++ would have an equivalent signature of
ReturnType foo(Type&& x)
On Wednesday, 3 October 2018 at 18:58:37 UTC, Shachar Shemesh
wrote:
On 03/10/18 20:43, Stanislav Blinov wrote:
On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh
wrote:
I.e. - I am asserting if a move was not caught. The program
fails to run on either ldc or dmd. To me, this
On Thursday, 4 October 2018 at 03:06:35 UTC, Shachar Shemesh
wrote:
If you do *anything* to that program, and that includes even
changing its compilation flags (try enabling inlining), it will
stop working.
You should have known that when you found out it doesn't work
on ldc: ldc and dmd us
On Thursday, 4 October 2018 at 08:32:44 UTC, Shachar Shemesh
wrote:
On 04/10/18 11:16, Paolo Invernizzi wrote:
While I want to thank you both, about the quality of this
thread, what kind of "consequences that go beyond what I think
you understand" are you thinking of? Can you give an example?
On Thursday, 4 October 2018 at 12:08:38 UTC, Shachar Shemesh
wrote:
Two distinct things. Kinke was talking about how to pass a
struct through the ABI. You are talking about special-casing a
specific name.
Not just name, but argument passing as well.
Not to mention, your special case is to t
On Sunday, 7 October 2018 at 02:01:17 UTC, Manu wrote:
The thing I'm trying to model is an attribute along the lines
of
`shared`, but actually useful ;)
I'll use the attribute `threadsafe` in place of `shared`, and
see
where that goes.
Consider:
struct Bob
{
int x;
threadsafe Atomic!int
On Sunday, 7 October 2018 at 04:16:43 UTC, Manu wrote:
We're not trying to 'stuff the nuances' into a keyword... what
I'm trying to achieve is a mechanism for attributing that a
function has
implemented thread-safety *in some way*, and how that works is a
detail for the function.
What the attr
On Friday, 5 October 2018 at 21:34:38 UTC, Jonathan M Davis wrote:
It's one of those things that I would have thought would just
be obvious with experience, but if nothing else, some folks
still try to stick to the whole "single return" idea even
though I think that most folks agree at this po
On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote:
"It takes care of itself
---
When writing a throwaway script...
...there's absolutely no need for a GC. In fact, the GC runtime
will only detract from performance.
What this means is that whenever I have
On Friday, 12 October 2018 at 17:31:30 UTC, Neia Neutuladh wrote:
Throwaway scripts can allocate a lot of memory and have
nontrivial running times. It's less common for scripts than for
long-running processes, granted, but I've written scripts to go
through gigabytes of data.
Your point bein
On Friday, 12 October 2018 at 18:50:26 UTC, Neia Neutuladh wrote:
Over the lifetime of the script, it processed more memory than
my computer had. That means I needed a memory management
strategy other than "allocate everything". The GC made that
quite easy.
Now *that* is a good point. Then a
On Friday, 12 October 2018 at 19:06:36 UTC, Dejan Lekic wrote:
What a bunch of nonsense! I used to talk like this some 20
years ago when all I saw in the computing world was C and C++...
Sure garbage collection is not for every project, depends what
industry you are in I guess... In my case (
On Friday, 12 October 2018 at 19:55:02 UTC, Nicholas Wilson wrote:
Freeing your mind and the codebase of having to deal with
memory leaves it in an easier place to deal with the less
common higher impact leaks: file descriptors, sockets, database
handles ect. (this is like chopping down the fo
On Friday, 12 October 2018 at 21:15:04 UTC, welkam wrote:
People in this thread mostly said that for some things GC is
just awesome. When you need to get shit done fast and dirty GC
saves time and mental capacity. Not all code deals with
sockets, DB, bank transactions, multithreading, etc.
R
On Friday, 12 October 2018 at 21:34:35 UTC, Atila Neves wrote:
---
When writing a throwaway script...
...there's absolutely no need for a GC.
True. There's also absolutely no need for computer languages
either, machine code is sufficient.
Funny. Now for real, i
On Friday, 12 October 2018 at 21:39:13 UTC, Atila Neves wrote:
D isn't Java. If you can, put your data on the stack. If you
can't, `new` away and don't think about it.
Then five years later, try and hunt down that mysterious heap
corruption. Caused by some destructor calling into buggy
third
On Friday, 12 October 2018 at 23:32:34 UTC, Nicholas Wilson wrote:
On Friday, 12 October 2018 at 20:12:26 UTC, Stanislav Blinov
That's done first and foremost by stripping out unnecessary
allocations, not by writing "new" every other line and closing
your eyes.
If you ne
On Saturday, 13 October 2018 at 12:15:07 UTC, rjframe wrote:
...I didn't even keep the script; I'll never need it again.
There are times when the easy or simple solution really is the
best one for the task at hand.
And?.. Would you now go around preaching how awesome the GC is
and that every
On Saturday, 13 October 2018 at 13:08:30 UTC, Atila Neves wrote:
On Friday, 12 October 2018 at 23:24:56 UTC, Stanislav Blinov
Funny. Now for real, in a throwaway script, what is there to
gain from a GC? Allocate away and forget about it.
In case you run out of memory, the GC scans. That&#
On Saturday, 13 October 2018 at 13:17:41 UTC, Atila Neves wrote:
Then five years later, try and hunt down that mysterious heap
corruption. Caused by some destructor calling into buggy
third-party code. Didn't want to think about that one either?
That hasn't happened to me.
It rarely does in
On Saturday, 13 October 2018 at 21:44:45 UTC, 12345swordy wrote:
Not everyone have the time nor skills of doing manual memory
management. Even more so when correctness is way more important
than speed.
Not everything needs to be fast.
That's a lamest excuse if I ever seen one. If you can't
On Sunday, 14 October 2018 at 20:26:10 UTC, 12345swordy wrote:
It not an excuse, it's reality. The d language have multiple
issues, the idea to have the language to have built in support
for GC is NOT one of them.
Read this thread again then, carefully. You *have to* understand
D's GC in ord
On Monday, 15 October 2018 at 10:11:15 UTC, rjframe wrote:
On Sat, 13 Oct 2018 12:22:29 +, Stanislav Blinov wrote:
And?.. Would you now go around preaching how awesome the GC is
and that everyone should use it?
For something like I did, yes.
The article the OP links to may want GC for
On Monday, 15 October 2018 at 16:46:45 UTC, 12345swordy wrote:
On Monday, 15 October 2018 at 00:02:31 UTC, Stanislav Blinov
wrote:
I'm arrogants, huh?
When you say statements like this.
you don't give a flying duck about your impact on the industry.
It come across as condesc
On Monday, 15 October 2018 at 18:00:24 UTC, 12345swordy wrote:
On Monday, 15 October 2018 at 17:30:28 UTC, Stanislav Blinov
wrote:
On Monday, 15 October 2018 at 16:46:45 UTC, 12345swordy wrote:
On Monday, 15 October 2018 at 00:02:31 UTC, Stanislav Blinov
wrote:
I'm arrogants, huh?
Whe
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Assuming the rules above: "can't read or write to members", and
the understanding that `shared` methods are expected to have
threadsafe implementations (because that's the whole point),
what are the risks from allowing T* -> shared(T)* co
On Monday, 15 October 2018 at 20:12:47 UTC, 12345swordy wrote:
On Monday, 15 October 2018 at 19:57:59 UTC, Stanislav Blinov
wrote:
If you want to have an argument, I suggest you stop quote
mining and start paying attention.
If you wanted an argument from me, then you need to stop with
the
On Monday, 15 October 2018 at 20:57:46 UTC, Manu wrote:
On Mon, Oct 15, 2018 at 1:15 PM Stanislav Blinov via
Digitalmars-d wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
> Assuming the rules above: "can't read or write to members",
> and the under
On Monday, 15 October 2018 at 21:51:43 UTC, Manu wrote:
If a shared method is incompatible with an unshared method,
your class is broken.
What?!? So... my unshared methods should also perform all that's
necessary for `shared` methods?
Explicit casting doesn't magically implement thread-saf
On Tuesday, 16 October 2018 at 00:15:54 UTC, Manu wrote:
On Mon, Oct 15, 2018 at 4:35 PM Stanislav Blinov via
Digitalmars-d wrote:
What?!? So... my unshared methods should also perform all
that's necessary for `shared` methods?
Of course! You're writing a threadsafe object... how
On Tuesday, 16 October 2018 at 03:00:21 UTC, Manu wrote:
I don't see how an *implicit* cast can be a restriction. At
all.
Because a shared pointer can't access anything.
You can't do anything with a shared instance, so the can be no
harm done.
That just doesn't compute. You obviously *can*
On Tuesday, 16 October 2018 at 11:42:55 UTC, Tony wrote:
On Monday, 15 October 2018 at 08:21:11 UTC, Eugene Wissner
He doesn't argue against garbage collection.
Thanks, Eugene, I was starting to lose hope in humanity.
Well, can you state what he does argue against?
I did state what I was
On Wednesday, 17 October 2018 at 05:40:41 UTC, Walter Bright
wrote:
When Andrei and I came up with the rules for:
mutable
const
shared
const shared
immutable
and which can be implicitly converted to what, so far nobody
has found a fault in those rules...
Here's one: shared -
Jesus Manu, it's soon 8 pages of dancing around a trivial issue.
Implicit casting from mutable to shared is unsafe, case closed.
Explicit cast from mutable to unsafe, on the other hand:
- is an assertion (on programmer's behalf) that this instance is
indeed unique
- is self-documenting
- is gr
On Wednesday, 17 October 2018 at 13:36:53 UTC, Stanislav Blinov
wrote:
Explicit cast from mutable to unsafe, on the other hand:
Blargh, to shared of course.
On Wednesday, 17 October 2018 at 14:44:19 UTC, Guillaume Piolat
wrote:
The fact that this _type constructor_ finds its way into
_identifiers_ create some concern:
https://github.com/dlang/phobos/blob/656798f2b385437c239246b59e0433148190938c/std/experimental/allocator/package.d#L642
Well, ISh
On Wednesday, 17 October 2018 at 14:14:56 UTC, Nicholas Wilson
wrote:
On Wednesday, 17 October 2018 at 07:24:13 UTC, Stanislav Blinov
wrote:
On Wednesday, 17 October 2018 at 05:40:41 UTC, Walter Bright
wrote:
When Andrei and I came up with the rules for:
mutable
const
shared
201 - 300 of 362 matches
Mail list logo
