that restriction when new GC
> > will be
> > implemented? removing the "@nogc" requirement on class dtors
> > will break
> > *nothing* *at* *all*. yet adding it now, while we don't have
> > that new
> > GC, will prevent alot of bugs that can
On Tuesday, 20 January 2015 at 18:25:42 UTC, ketmar via
Digitalmars-d wrote:
how likely this to be changed? is there *any* chances of that
in 2015?
2016? and why we can't just remove that restriction when new GC
will be
implemented? removing the "@nogc" requirement on class dt
r (of course, everyone doesn't use
dscanner). Someone who wants to avoid hidden allocations in a
destructor will mark all their class destructors @nogc anyway, so
enforcing it seems like it wouldn't add much value over what can
already be done.
On Tue, 20 Jan 2015 18:17:56 +
Meta via Digitalmars-d wrote:
> On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via
> Digitalmars-d wrote:
> > Hello.
> >
> > as there is no possibility to doing GC allocations in class
> > destructors, wouldn
On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via
Digitalmars-d wrote:
Hello.
as there is no possibility to doing GC allocations in class
destructors, wouldn't it be nice to just force "@nogc"
attribute on
such dtors?
i know, i know, "this will break alot of co
Hello.
as there is no possibility to doing GC allocations in class
destructors, wouldn't it be nice to just force "@nogc" attribute on
such dtors?
i know, i know, "this will break alot of code". i'm pretty sure that
this will break alot of INVALID code, which be
On Thursday, 4 December 2014 at 23:22:04 UTC, deadalnix wrote:
I don't think this is solving the same problem as Marc's
proposal so I'm not sure how comparing them make sense. Marc's
proposal is about manipulating data without having ownership.
This defines ownership.
Indeed. But both combine
ze + added expressiveness
(ie interaction of GC and no gc code, ownership transfers, safe
reference counting, extension of possibilities in @nogc code in a
similar fashion as weakly pure allow for extra expressiveness in
pure code).
If you allow me for a non politically correct metaphor, would you
b
Finally got a look at your proposal. While I do agree with many
initial statements and, specifically, proposal for heap
segregation, proposed semantics of `owned` does leave me
skeptical. It is effectively a more refined/mature approach to
"cooking of immutables" concept and Marc proposal, whil
On 11/21/2014 04:36 AM, Jonathan Marler wrote:
This could be useful for the standard library to expose different
implementations based on whether or not the application is using the GC.
https://issues.dlang.org/show_bug.cgi?id=9511
W dniu 2014-11-22 o 17:56, Ary Borenszweig pisze:
On 11/21/14, 12:36 AM, Jonathan Marler wrote:
Has the idea of function overloading via nogc been explored?
void func() @nogc
{
// logic that does not use GC
}
void func()
{
// logic that uses GC
}
void main(string[] args) // @nogc
On Saturday, 22 November 2014 at 16:56:58 UTC, Ary Borenszweig
wrote:
On 11/21/14, 12:36 AM, Jonathan Marler wrote:
Has the idea of function overloading via nogc been explored?
void func() @nogc
{
// logic that does not use GC
}
void func()
{
// logic that uses GC
}
void main(string
On Friday, 21 November 2014 at 03:36:30 UTC, Jonathan Marler
wrote:
Has the idea of function overloading via nogc been explored?
void func() @nogc
{
// logic that does not use GC
}
void func()
{
// logic that uses GC
}
void main(string[] args) // @nogc
{
// if main is @nogc, then
On Sunday, 23 November 2014 at 08:57:15 UTC, Kapps wrote:
Instead consider passing in an allocator. Then it's explicit,
more flexible, and more different.
More apparent rather. Auto correct messed it up then hit send
trying to touch the word to select it. -_-
On 11/21/14, 12:36 AM, Jonathan Marler wrote:
Has the idea of function overloading via nogc been explored?
void func() @nogc
{
// logic that does not use GC
}
void func()
{
// logic that uses GC
}
void main(string[] args) // @nogc
{
// if main is @nogc, then the @nogc version of
W dniu 2014-11-21 o 04:36, Jonathan Marler pisze:
Has the idea of function overloading via nogc been explored?
void func() @nogc
{
// logic that does not use GC
}
void func()
{
// logic that uses GC
}
void main(string[] args) // @nogc
{
// if main is @nogc, then the @nogc version
What would be the next step to keep this effort going forward ?
A POC implementation would be a lot of work but it would also
help people detect corner cases or unsuspected interaction with
some features of the language.
"Jonathan Marler" wrote in message
news:huzhibjpuvqjxqnub...@forum.dlang.org...
Has the idea of function overloading via nogc been explored?
void func() @nogc
{
// logic that does not use GC
}
void func()
{
// logic that uses GC
}
void main(string[] args) // @nogc
{
Has the idea of function overloading via nogc been explored?
void func() @nogc
{
// logic that does not use GC
}
void func()
{
// logic that uses GC
}
void main(string[] args) // @nogc
{
// if main is @nogc, then the @nogc version of func
// will be called, otherwise, the GC
On Tuesday, 18 November 2014 at 20:34:01 UTC, Ola Fosheim Grøstad
wrote:
Does this mean that you need all threads (which I presume are
the mutators) to be in an eventloop in order to collect?
What you need is for each thread to provide you a list of roots.
You can start tracing while having a
On Saturday, 15 November 2014 at 20:13:47 UTC, deadalnix wrote:
On Saturday, 15 November 2014 at 12:52:33 UTC, Ola Fosheim
Grøstad wrote:
Thanks for the link! I agree ML has some interesting work done
for it, but they make some assumptions:
1. low portion of mutable objects
2. small heap fits
On Tuesday, 18 November 2014 at 02:39:48 UTC, Walter Bright wrote:
On 11/17/2014 1:57 PM, deadalnix wrote:
2. I'm not sure if that is enough to make it work. It is worth
investigating. It is gonna be much more limited than what I
have
in mind.
There was a lot of skepticism initially when I p
On 11/17/2014 1:57 PM, deadalnix wrote:
2. I'm not sure if that is enough to make it work. It is worth
investigating. It is gonna be much more limited than what I have
in mind.
There was a lot of skepticism initially when I proposed that ref be a storage
class rather than a type constructor, b
a smidgen
of compiler help.
Ok, I'm gonna respond in reverse order, so I can use one answer
as a starting point for the next one.
3. This is not doable as a library type. The proposal interact
with @nogc, pure function and exception handling. There is no way
to make it @saf
On Sunday, 16 November 2014 at 10:21:53 UTC, Marc Schütz wrote:
On Friday, 14 November 2014 at 21:59:47 UTC, deadalnix wrote:
On Friday, 14 November 2014 at 11:46:51 UTC, Marc Schütz wrote:
That is a well covered subject and told you what to google for
as
well as the basic approach. Your exampl
Nice article.
Some observations:
1. I don't understand the difference between 'unique', 'owned' and 'isolated'.
(Some other systems use 'isolated'.) Is there a difference?
2. I suspect that 'owned' does not need to be a type qualifier - it can be a
storage class much like 'ref' is. This make
On Friday, 14 November 2014 at 21:59:47 UTC, deadalnix wrote:
On Friday, 14 November 2014 at 11:46:51 UTC, Marc Schütz wrote:
That is a well covered subject and told you what to google for
as
well as the basic approach. Your example here simply told me you
haven't done your homework before post
On Saturday, 15 November 2014 at 12:52:33 UTC, Ola Fosheim
Grøstad wrote:
Thanks for the link! I agree ML has some interesting work done
for it, but they make some assumptions:
1. low portion of mutable objects
2. small heap fits in per-core-cache (<256KiB on Haswell).
So the small heap is ba
On Saturday, 15 November 2014 at 00:16:22 UTC, deadalnix wrote:
The idea is based on Doligez-Leroy's GC, but using TL heap as
the
small object and immutable heap as the shared. Note that this GC
is done for ML, where most things are immutable and this is why
it works well (only require write bar
ML is interesting because it emphasis immutability. For
performance reasons, a part of it is in effect mutable and thread
local. Some ML implementations are very interesting for us.
But let's get back to D. To make the example simpler, let's get
rid of shared (in effect, the same thing can be ach
On Friday, 14 November 2014 at 20:22:13 UTC, Marc Schütz wrote:
It needs to be `owned(Exception)`, otherwise, how could the
compiler know how to treat it correctly? But declaring foo() in
that way would be unhelpful, because it would move the
exception on calling the function, which is usually
On Friday, 14 November 2014 at 21:59:47 UTC, deadalnix wrote:
That is a well covered subject and told you what to google for
as
well as the basic approach. Your example here simply told me you
haven't done your homework before posting.
Please go look into scientific documentation about GC for M
On Friday, 14 November 2014 at 11:46:51 UTC, Marc Schütz wrote:
On Thursday, 13 November 2014 at 22:12:22 UTC, deadalnix wrote:
You need a set of root from the TL heap. The trick being to
consider everything that is allocated AFTER you get the roots
as
automatically alive (you'll collect this
On Friday, 14 November 2014 at 19:02:52 UTC, Dmitry Olshansky
wrote:
Here is the case I wanted to check:
try{
...
}
catch(owned(Exception) e){
foo(e);
}
void foo(T)(T arg){
// what would this print? Exception or owned(Exception)
// do we bloat a bit more on quali
t
definition of things, what is forbidden in @nogc code is to consume the
owned in such a fashion that its island is merged into TL, shared or
immutable heap. If you don't do this, then your isolated will be freed
when going out of scope and the GC won't need to kick in/no garbage will
be
On Thursday, 13 November 2014 at 22:12:22 UTC, deadalnix wrote:
You need a set of root from the TL heap. The trick being to
consider everything that is allocated AFTER you get the roots as
automatically alive (you'll collect this in the next collection
cycle).
That way, new allocated chunk that
On Friday, 14 November 2014 at 01:05:13 UTC, Walter Bright wrote:
On 11/11/2014 6:34 PM, deadalnix wrote:
On an implementation level, a call to a pure function that
return an owned could
look like this :
{
IslandID __saved = gc_switch_new_island();
scope(exit) gc_restore_island(__saved);
On 11/11/2014 6:34 PM, deadalnix wrote:
On an implementation level, a call to a pure function that return an owned could
look like this :
{
IslandID __saved = gc_switch_new_island();
scope(exit) gc_restore_island(__saved);
call_pure_function();
}
This allow us to rely much less on the
On Thursday, 13 November 2014 at 14:26:44 UTC, Marc Schütz wrote:
The important part is that owning, RC and GC types all need to
know the allocators they belong to. In my example I need that
to allow Owned types to be converted to RC types. In your
proposal, something similar will ultimately be
On Thursday, 13 November 2014 at 10:10:34 UTC, Marc Schütz wrote:
On Wednesday, 12 November 2014 at 21:15:05 UTC, deadalnix wrote:
On Wednesday, 12 November 2014 at 12:49:41 UTC, Marc Schütz
wrote:
All this is unfortunately only true if there are no
references between heaps, i.e. if the heaps a
want to get safety and the full benefit
out of it, as it would require for the compiler to introduce
some call to the runtime at strategic places and it does
interact with @nogc.
I'm not sure. A library implementation may be feasible. For
invalidation, the objects can be returned to their
On Thursday, 13 November 2014 at 10:10:34 UTC, Marc Schütz wrote:
potentially have references to it. They either need to be
stopped, or write barriers need to be utilized when references
to immutable data are changed.
I sometimes wonder if the very pragmatic and brutal option of
just having G
On Wednesday, 12 November 2014 at 21:15:05 UTC, deadalnix wrote:
On Wednesday, 12 November 2014 at 12:49:41 UTC, Marc Schütz
wrote:
All this is unfortunately only true if there are no references
between heaps, i.e. if the heaps are indeed "islands".
Otherwise, there need to be at least write ba
heap anyway? I take it that if I don't save exception
explicitly anywhere the owned island is destroyed at catch
scope?
Yes it touches the heap. But as long as things are owned, they'll
be freed automatically when going out of scope. That means, with
that definition of things, what i
On Wednesday, 12 November 2014 at 12:49:41 UTC, Marc Schütz wrote:
All this is unfortunately only true if there are no references
between heaps, i.e. if the heaps are indeed "islands".
Otherwise, there need to be at least write barriers.
Yes, that is exactly why I'm listing the case where th
deduced by compiler in case of
pure functions? Also it seem templates should not take owned(T) into
consideration and let it decay... How does owned compose with other
qualifiers?
@nogc . Remember ? It was in the title. What does a @nogc function look
like ? a no gc function o not produce a
for the compiler to introduce some
call to the runtime at strategic places and it does interact
with @nogc.
I'm not sure. A library implementation may be feasible. For
invalidation, the objects can be returned to their init state.
This is "safe", but maybe not ideal, as a compi
allocation is
close to what C++'s stdlib is doing, and even if the proposed
approach by Andrei is better, I don't think this is a good one.
The proposed approach allow for a lot of code to be marked as
@nogc and allow for the caller to decide. That is ultimately
what we want librarie
On Wednesday, 12 November 2014 at 11:51:11 UTC, ponce wrote:
Haswell does not have buffered transactions so you wait for
the commit, but there are presentations out where Intel has
put buffered transactions at around 2017… (but I would expect
a delay).
I wasn't arguing of the current performa
On Wednesday, 12 November 2014 at 11:19:59 UTC, Ola Fosheim
Grøstad wrote:
STM = software based transactional memory (without hardware
support)
I was meaning HTM instead, good catch.
Haswell does not have buffered transactions so you wait for the
commit, but there are presentations out where
On Wednesday, 12 November 2014 at 11:08:41 UTC, ponce wrote:
I actually tested Haswell HLE and was underwhelmed (not the
full STM, was just trying to get more out of some locks).
STM = software based transactional memory (without hardware
support)
Haswell does not have buffered transactions
On Wednesday, 12 November 2014 at 09:56:57 UTC, Paulo Pinto
wrote:
On Wednesday, 12 November 2014 at 08:55:30 UTC, deadalnix wrote:
On Wednesday, 12 November 2014 at 08:38:14 UTC, Ola Fosheim
In addition, the whole
CPU industry is backpedaling on the transactional memory
concept. That is aweso
On Wednesday, 12 November 2014 at 08:55:30 UTC, deadalnix wrote:
On Wednesday, 12 November 2014 at 08:38:14 UTC, Ola Fosheim
In addition, the whole
CPU industry is backpedaling on the transactional memory
concept. That is awesome on the paper, but it didn't worked.
Given the support on Haskell
On Wednesday, 12 November 2014 at 08:55:30 UTC, deadalnix wrote:
I'm sorry to be blunt, but there is nothing actionable in your
comment. You are just throwing more and more into the pot until
nobody know what there is in. But ultimately, the crux of the
problem is the thing quoted above.
My p
On Wednesday, 12 November 2014 at 08:38:14 UTC, Ola Fosheim
Grøstad wrote:
That changes over time. The current focus in upcoming hardware
is on:
1. Heterogenous architecture with high performance co-processors
2. Hardware support for transactional memory
Intel CPUs might have buffered transac
pments. The way to do it is:
1. Accept that generally performant multi-threaded code is unsafe
and application/hardware optimized.
2. Focus on making @nogc single-threaded code robust and fast.
And I agree that ownership is key.
3. Use semantic analysis to automatically generate a tailored
runtime with application-optimized allocators.
strategic places and it does interact with @nogc.
On Wednesday, 12 November 2014 at 06:16:34 UTC, Walter Bright
wrote:
On 11/11/2014 6:34 PM, deadalnix wrote:
> [...]
Thanks for an excellent summary of the problem. I can't just
read your solution and know it works, it'll take some time.
That is quite difficult to explain with drawing. Maybe
On 11/11/2014 6:34 PM, deadalnix wrote:
> [...]
Thanks for an excellent summary of the problem. I can't just read your solution
and know it works, it'll take some time.
re_island(__saved);
call_pure_function();
}
This allow us to rely much less on the GC and allow for a better GC
implementation.
@nogc . Remember ? It was in the title. What does a @nogc function look
like ? a no gc function o not produce any garbage or trigger the
collection cycle. there is no
tion level, a call to a pure function that
return an owned could look like this :
{
IslandID __saved = gc_switch_new_island();
scope(exit) gc_restore_island(__saved);
call_pure_function();
}
This allow us to rely much less on the GC and allow for a
better GC implementation.
@nogc . Reme
ld look like this :
{
IslandID __saved = gc_switch_new_island();
scope(exit) gc_restore_island(__saved);
call_pure_function();
}
This allow us to rely much less on the GC and allow for a better
GC implementation.
@nogc . Remember ? It was in the title. What does a @nogc
function look
On Tuesday, 11 November 2014 at 17:56:50 UTC, David Nadlinger
wrote:
On Tuesday, 11 November 2014 at 17:53:43 UTC, David Nadlinger
wrote:
Let's focus work on finally fixing bug 2834 instead.
(https://issues.dlang.org/show_bug.cgi?id=2834 – "Struct
Destructors are not called by the GC, but cal
On Tuesday, 11 November 2014 at 17:53:43 UTC, David Nadlinger
wrote:
Let's focus work on finally fixing bug 2834 instead.
(https://issues.dlang.org/show_bug.cgi?id=2834 – "Struct
Destructors are not called by the GC, but called on explicit
delete". To me, this seems to be the proper fix for y
On Monday, 10 November 2014 at 12:59:14 UTC, Tomer Filiba wrote:
http://wiki.dlang.org/DIP68
To be honest, I don't think that this DIP adds significant value
to the language. Generally, you (as in a language/library
implementor) need to assume that *any* struct with a non-trivial
destructor
I don't see the merit of this DIP and it clearly introduces whole
new meaning of @nogc attribute (which needs a really good
justification to pull it off)
On 2014-11-11 14:19, Tomer Filiba wrote:
__trait(getFunctionAttributes, F) -- but it returns flags that are
applicable only to function attributes
Hmm, yeah. Using that trait on a type might be a bit weird.
--
/Jacob Carlborg
No, a trait or template to find out if a function is @nogc.
__trait(getFunctionAttributes, F) -- but it returns flags that
are applicable only to function attributes
-tomer
stic properties.
But the DIP is also underspecified. E.g., is it allowed to
embed a @nogc type in a class? If not, what if that class again
is wrapped in std.typecons.Scoped?
I thought I covered it there, but just to be clear, @nogc should
be inherited by the containing type, so if a class has
On 2014-11-10 20:19, bearophile wrote:
Do you mean we already have a trait for a feature that doesn't yet
exists? :-)
No, a trait or template to find out if a function is @nogc.
--
/Jacob Carlborg
IP is also underspecified. E.g., is it allowed to embed
a @nogc type in a class? If not, what if that class again is
wrapped in std.typecons.Scoped?
On 11/10/2014 4:59 AM, Tomer Filiba wrote:
http://wiki.dlang.org/DIP68
This DIP proposes the addition of a compiler-enforced @nogc attribute on types.
This means means such a type cannot be allocated by the GC, e.g., using operator
new on such a type or appending such a type to a dynamic array
On Monday, 10 November 2014 at 12:59:14 UTC, Tomer Filiba wrote:
http://wiki.dlang.org/DIP68
This DIP proposes the addition of a compiler-enforced @nogc
attribute on types.
I would probably suggest extending this to variables.
class Foo {
@nogc Bar var1;
void doStuff
Jacob Carlborg:
Don't we have something for that already?
Do you mean we already have a trait for a feature that doesn't
yet exists? :-)
Bye,
bearophile
On 2014-11-10 14:58, bearophile wrote:
Perhaps your DIP also needs a trait?
Don't we have something for that already?
--
/Jacob Carlborg
Tomer Filiba:
http://wiki.dlang.org/DIP68
Perhaps your DIP also needs a trait?
struct Foo {}
@nogc struct Bar {}
static assert(!__traits(hasNogc, Foo));
static assert(__traits(hasNogc, Bar));
Byem
bearophile
http://wiki.dlang.org/DIP68
This DIP proposes the addition of a compiler-enforced @nogc
attribute on types. This means means such a type cannot be
allocated by the GC, e.g., using operator new on such a type or
appending such a type to a dynamic array, would result in
compile-time errors
On Tuesday, September 30, 2014 15:18:17 Jacob Carlborg via Digitalmars-d
wrote:
> On 30/09/14 14:29, Andrei Alexandrescu wrote:
> > Good point. We need to think about that.
>
> Weren't all methods in Object supposed to be lifted out from Object anyway?
Yes, but not much work has been done on it,
Am Wed, 01 Oct 2014 02:21:44 -0700
schrieb Andrei Alexandrescu :
> On 9/30/14, 9:49 AM, Johannes Pfau wrote:
> > I guess my point is that although RC is useful in some cases output
> > ranges / sink delegates / pre-allocated buffers are still necessary
> > in other cases and RC is not the solution
On 10/5/14, 1:58 AM, "Marc Schütz" " wrote:
There was indeed agreement on reference counting (although someone
suggested disallowing cycles or removing chaining altogether). But what
I meant is that there was no agreement on a specific solution, and
several ones were proposed, from full general c
ет:
lately when working on std.string I run into problems
making stuff nogc
as std.utf.decode is not nogc.
https://issues.dlang.org/show_bug.cgi?id=13458
Trivial to do. But before that somebody got to make one of:
a) A policy on reuse of exceptions. Literally we have easy
TLS why not
put
On 10/4/14, 4:24 AM, "Marc Schütz" " wrote:
On Friday, 3 October 2014 at 19:51:40 UTC, Andrei Alexandrescu wrote:
On 10/3/14, 11:35 AM, Dmitry Olshansky wrote:
01-Oct-2014 14:10, Robert burner Schadek пишет:
lately when working on std.string I run into problems makin
On Friday, 3 October 2014 at 19:51:40 UTC, Andrei Alexandrescu
wrote:
On 10/3/14, 11:35 AM, Dmitry Olshansky wrote:
01-Oct-2014 14:10, Robert burner Schadek пишет:
lately when working on std.string I run into problems making
stuff nogc
as std.utf.decode is not nogc.
https://issues.dlang.org
On 10/3/14, 3:59 PM, Dmitry Olshansky wrote:
Got it:
https://gist.github.com/DmitryOlshansky/d718be4ec12158cf2f02
Tries hard to detect class & function name (it's all on heuristics +
regex... e-hm) and generates mediawiki table.
DWiki won't let me edit it, but the output is here:
https://gist.g
04-Oct-2014 00:56, Dmitry Olshansky пишет:
04-Oct-2014 00:42, Dmitry Olshansky пишет:
04-Oct-2014 00:21, Dmitry Olshansky пишет:
04-Oct-2014 00:21, Andrei Alexandrescu пишет:
On 10/3/14, 1:18 PM, Dmitry Olshansky wrote:
03-Oct-2014 23:50, Andrei Alexandrescu пишет:
[snip]
Glad you liked it.
04-Oct-2014 00:42, Dmitry Olshansky пишет:
04-Oct-2014 00:21, Dmitry Olshansky пишет:
04-Oct-2014 00:21, Andrei Alexandrescu пишет:
On 10/3/14, 1:18 PM, Dmitry Olshansky wrote:
03-Oct-2014 23:50, Andrei Alexandrescu пишет:
[snip]
Glad you liked it.
Being in favor of automation as a start I
04-Oct-2014 00:21, Dmitry Olshansky пишет:
04-Oct-2014 00:21, Andrei Alexandrescu пишет:
On 10/3/14, 1:18 PM, Dmitry Olshansky wrote:
03-Oct-2014 23:50, Andrei Alexandrescu пишет:
[snip]
Glad you liked it.
Being in favor of automation as a start I just toggled -vgc flag in
Win64 makefile and
On 10/3/14, 1:18 PM, Dmitry Olshansky wrote:
03-Oct-2014 23:50, Andrei Alexandrescu пишет:
On 10/3/14, 11:27 AM, Dmitry Olshansky wrote:
29-Sep-2014 14:49, Andrei Alexandrescu пишет:
Back when I've first introduced RCString I hinted that we have a larger
strategy in mind. Here it is.
[snip]
04-Oct-2014 00:21, Andrei Alexandrescu пишет:
On 10/3/14, 1:18 PM, Dmitry Olshansky wrote:
03-Oct-2014 23:50, Andrei Alexandrescu пишет:
On 10/3/14, 11:27 AM, Dmitry Olshansky wrote:
29-Sep-2014 14:49, Andrei Alexandrescu пишет:
Back when I've first introduced RCString I hinted that we have a
03-Oct-2014 23:50, Andrei Alexandrescu пишет:
On 10/3/14, 11:27 AM, Dmitry Olshansky wrote:
29-Sep-2014 14:49, Andrei Alexandrescu пишет:
Back when I've first introduced RCString I hinted that we have a larger
strategy in mind. Here it is.
[snip]
I think it would be well worth it to actually
03-Oct-2014 23:51, Andrei Alexandrescu пишет:
On 10/3/14, 11:35 AM, Dmitry Olshansky wrote:
01-Oct-2014 14:10, Robert burner Schadek пишет:
lately when working on std.string I run into problems making stuff nogc
as std.utf.decode is not nogc.
https://issues.dlang.org/show_bug.cgi?id=13458
On 10/3/14, 11:27 AM, Dmitry Olshansky wrote:
29-Sep-2014 14:49, Andrei Alexandrescu пишет:
Back when I've first introduced RCString I hinted that we have a larger
strategy in mind. Here it is.
[snip]
I think it would be well worth it to actually do a bit of research.
Before we get into the f
On 10/3/14, 11:35 AM, Dmitry Olshansky wrote:
01-Oct-2014 14:10, Robert burner Schadek пишет:
lately when working on std.string I run into problems making stuff nogc
as std.utf.decode is not nogc.
https://issues.dlang.org/show_bug.cgi?id=13458
Trivial to do. But before that somebody got to
01-Oct-2014 14:10, Robert burner Schadek пишет:
lately when working on std.string I run into problems making stuff nogc
as std.utf.decode is not nogc.
https://issues.dlang.org/show_bug.cgi?id=13458
Trivial to do. But before that somebody got to make one of:
a) A policy on reuse of
29-Sep-2014 14:49, Andrei Alexandrescu пишет:
Back when I've first introduced RCString I hinted that we have a larger
strategy in mind. Here it is.
[snip]
I think it would be well worth it to actually do a bit of research.
Before we get into the fry and spill blood (or LOCs) everywhere.
Can w
On Friday, 3 October 2014 at 17:01:46 UTC, H. S. Teoh via
Digitalmars-d wrote:
For a compile-string that's statically fixed (i.e.,
writefln!"..."(...)), we can do a lot more than what ctFmt
does. For
example, we can parse the format at compile-time to extract
individual
formatting specifiers an
On Friday, 3 October 2014 at 17:01:46 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Oct 03, 2014 at 11:15:28AM +, monarch_dodra via
Digitalmars-d wrote:
On Thursday, 2 October 2014 at 23:32:32 UTC, H. S. Teoh via
Digitalmars-d
wrote:
>Alright, today I drafted up the following proof of co
On Fri, Oct 03, 2014 at 11:15:28AM +, monarch_dodra via Digitalmars-d wrote:
> On Thursday, 2 October 2014 at 23:32:32 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >Alright, today I drafted up the following proof of concept:
> >
> >[...]
> >
> >writefln!"Number: %d Tag: %s"(123, "mytag");
>
>
On Fri, Oct 03, 2014 at 07:38:22AM +, Andrei Alexandrescu via Digitalmars-d
wrote:
> "H. S. Teoh via Digitalmars-d" wrote:
> > On Sat, Sep 27, 2014 at 01:06:24PM +0200, Andrej Mitrovic via Digitalmars-d
> > wrote:
> >> On 9/27/14, H. S. Teoh via Digitalmars-d
> >> wrote:
> >>> writefln!"
On Thursday, 2 October 2014 at 23:32:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
Alright, today I drafted up the following proof of concept:
[...]
writefln!"Number: %d Tag: %s"(123, "mytag");
I had (amongst with others) thought about the possibility of
"ct-write".
I think an even more powe
701 - 800 of 1445 matches
Mail list logo
