On Sunday, 5 August 2018 at 20:57:32 UTC, aliak wrote:
On Sunday, 5 August 2018 at 20:10:49 UTC, Kamil Koczurek wrote:
Is there a way to keep track of objects without owning them?
That is, could I have a smart pointer that behaves somewhat
like this:
WeakPtr!Class wptr = getSomeInstance();
On Sunday, 5 August 2018 at 20:10:49 UTC, Kamil Koczurek wrote:
Is there a way to keep track of objects without owning them?
That is, could I have a smart pointer that behaves somewhat
like this:
WeakPtr!Class wptr = getSomeInstance();
auto obj = wptr.peek; //[1]
if(obj !is null) {
Is there a way to keep track of objects without owning them? That
is, could I have a smart pointer that behaves somewhat like this:
WeakPtr!Class wptr = getSomeInstance();
auto obj = wptr.peek; //[1]
if(obj !is null) {
obj.stuff();
}
[1]: If wptr points to something that is still reachable
Thankyou.
On Saturday, 4 August 2018 at 12:54:49 UTC, Steven Schveighoffer
wrote:
Once you have an alias, it's the original thing in all
respects. So there's no way to get the specific alias that was
used. That's not a bug, but a feature.
Aha. Thanks.
I've tried std.traits.TemplateOf and
On Sunday, 5 August 2018 at 12:23:17 UTC, vit wrote:
Yes, it isn't possible.
I modify filter a and map from std.algorithm:
void main()@nogc{
import std.experimental.all;
const int j = 2;
int i = 0;
const int[3] tmp = [1, 2, 3];
tmp[]
On 05.08.2018 16:07, Steven Schveighoffer wrote:
I have found something that looks like a bug to me, but also looks like
it could simply be a limitation of the foreach construct.
Consider this code:
struct Foo {}
enum isFoo(alias x) = is(typeof(x) == Foo);
void main()
{
Foo foo;
On Sunday, 5 August 2018 at 14:07:30 UTC, Steven Schveighoffer
wrote:
I have found something that looks like a bug to me, but also
looks like it could simply be a limitation of the foreach
construct.
Consider this code:
struct Foo {}
enum isFoo(alias x) = is(typeof(x) == Foo);
void main()
I have found something that looks like a bug to me, but also looks like
it could simply be a limitation of the foreach construct.
Consider this code:
struct Foo {}
enum isFoo(alias x) = is(typeof(x) == Foo);
void main()
{
Foo foo;
assert(isFoo!foo);
static struct X { int i; Foo
On 8/5/18 8:23 AM, vit wrote:
On Sunday, 5 August 2018 at 10:57:32 UTC, Steven Schveighoffer wrote:
On 8/5/18 5:20 AM, vit wrote:
It's possible create something like this without errors?
void main()@nogc{ //Error: function `app.main` is `@nogc`
// yet allocates
On 2018-08-05 10:30, Bastiaan Veelo wrote:
You mean the dependency range in dub.selections.json of an app on
code.dlang.org? I would be in favour of it being a range, but I think
that is unusual. Usually people just commit the generated file unedited,
which seems to always be pinned to the
On Sunday, 5 August 2018 at 10:57:32 UTC, Steven Schveighoffer
wrote:
On 8/5/18 5:20 AM, vit wrote:
It's possible create something like this without errors?
void main()@nogc{ //Error: function `app.main` is `@nogc`
// yet allocates closures with the GC
import
On 8/5/18 5:20 AM, vit wrote:
It's possible create something like this without errors?
void main()@nogc{ //Error: function `app.main` is `@nogc`
// yet allocates closures with the GC
import std.experimental.all;
const int j = 2;
int i = 0;
const
On Sunday, 5 August 2018 at 10:12:39 UTC, Alex wrote:
On Sunday, 5 August 2018 at 01:15:07 UTC, Nicholas Wilson wrote:
On Saturday, 4 August 2018 at 18:12:05 UTC, Alex wrote:
On Saturday, 4 August 2018 at 13:26:01 UTC, Nicholas Wilson
That is a very long stacks trace and combined with the very
On Sunday, 5 August 2018 at 09:20:21 UTC, vit wrote:
It's possible create something like this without errors?
void main()@nogc{ //Error: function `app.main` is `@nogc`
// yet allocates closures with the GC
import std.experimental.all;
const int j = 2;
int i =
On Sunday, 5 August 2018 at 01:15:07 UTC, Nicholas Wilson wrote:
On Saturday, 4 August 2018 at 18:12:05 UTC, Alex wrote:
On Saturday, 4 August 2018 at 13:26:01 UTC, Nicholas Wilson
That is a very long stacks trace and combined with the very
short stack trace on OSX, this is probably a stack
It's possible create something like this without errors?
void main()@nogc{ //Error: function `app.main` is `@nogc`
// yet allocates closures with the GC
import std.experimental.all;
const int j = 2;
int i = 0;
const int[3] tmp = [1, 2, 3];
tmp[]
On Saturday, 4 August 2018 at 17:53:45 UTC, Neia Neutuladh wrote:
On Friday, 3 August 2018 at 19:41:32 UTC, Bastiaan Veelo wrote:
But if you commit it, and a compiler deprecation causes a
dependency in that pinned version to fail to compile, then
your app won't compile either, even though your
18 matches
Mail list logo
