On Wednesday, 29 August 2018 at 05:01:14 UTC, Walter Bright wrote:
On 8/25/2018 5:42 AM, Chris M. wrote:
What about my other point then on the syntax? I think
something similar to what I suggested would be a much more
flexible solution and is worth considering.
Much more work would be needed
On Thursday, 30 August 2018 at 16:57:05 UTC, Maksim Fomin wrote:
My point is somewhat different from expressed already here by
Jonathan. He speaks about whitelisting/blacklisting and that
the former model will always contain loopholes. In my view, the
reason is that memory safety in
On Wednesday, 29 August 2018 at 13:53:42 UTC, Nicholas Wilson
wrote:
On Wednesday, 29 August 2018 at 08:35:30 UTC, Walter Bright
wrote:
On 8/28/2018 10:18 PM, Nicholas Wilson wrote:
Bugzilla is not documentation. These are language changes
they need to be in release notes and the spec.
You
On Friday, 17 August 2018 at 07:19:25 UTC, Peter Alexander wrote:
My question is: what is the status of @safe? I am quite
surprised to see such a simple case fail. Is @safe believed to
be fully implemented (modulo bugs) and this is just an
unfortunate corner case, or is it known
On Wednesday, 29 August 2018 at 08:35:30 UTC, Walter Bright wrote:
On 8/28/2018 10:18 PM, Nicholas Wilson wrote:
Bugzilla is not documentation. These are language changes they
need to be in release notes and the spec.
You asked for a clue: "we have no clue WTF its supposed to do
or why the
On 8/28/2018 10:18 PM, Nicholas Wilson wrote:
Bugzilla is not documentation. These are language changes they need to be in
release notes and the spec.
You asked for a clue: "we have no clue WTF its supposed to do or why the changes
are being made" and there it is. There are no barriers to
On 8/23/2018 6:10 AM, Atila Neves wrote:
--
struct S {
int x;
@safe int* foo() { return }
}
--
% dmd -o- -dip1000 foo.d
% echo $?
0
struct S {
int x;
@safe int* foo() { return }
}
int* bar() {
S s;
return s.foo();
}
dmd test -dip1000
test.d(3):
On Wednesday, 29 August 2018 at 05:04:22 UTC, Walter Bright wrote:
On 8/25/2018 4:09 AM, Nicholas Wilson wrote:
On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright
wrote:
I'm not hostile to debate. I just don't care for "this is
uncharted territory, so let's do nothing" which has been
On 8/28/2018 6:12 AM, Steven Schveighoffer wrote:
So this would mean a member function would have to be refactored into a
different function with a different calling syntax. i.e:
x.foo(target);
would have to be refactored to:
target.foo(x);
or foo(target, x);
Maybe it should be anyway.
On 8/25/2018 4:09 AM, Nicholas Wilson wrote:
On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright wrote:
I'm not hostile to debate. I just don't care for "this is uncharted territory,
so let's do nothing" which has been going on for probably 4 years now,
coincident with "scope is
On 8/25/2018 5:42 AM, Chris M. wrote:
What about my other point then on the syntax? I think something similar to what
I suggested would be a much more flexible solution and is worth considering.
Much more work would be needed to make that a proposal.
On 8/24/18 10:25 PM, Walter Bright wrote:
On 8/23/2018 6:32 AM, Steven Schveighoffer wrote:
Furthermore any member function (or UFCS function for that matter)
REQUIRES the first parameter to be the aggregate. How do you make a
member function that stuffs the return into a different parameter
On 8/24/18 10:28 PM, Walter Bright wrote:
On 8/23/2018 8:14 AM, Steven Schveighoffer wrote:
If I had to design a specific way to allow the common case to be easy,
but still provide a mechanism for the uncommon cases, I would say:
1. define a compiler-recognized attribute (e.g. @__sink).
2. If
On Saturday, 25 August 2018 at 02:37:00 UTC, Walter Bright wrote:
On 8/23/2018 5:58 PM, Chris M. wrote:
Seems to be more of a warning of what issues we may face if
DIP25/DIP1000 are finally implemented. It would be good to
consider NLLs as well before D is committed. No point in
repeating
On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright wrote:
I'm not hostile to debate. I just don't care for "this is
uncharted territory, so let's do nothing" which has been going
on for probably 4 years now, coincident with "scope is
incomplete, D sux".
I.e. lead, follow, or get out
On 8/23/2018 5:58 PM, Chris M. wrote:
Seems to be more of a warning of what issues we may face if DIP25/DIP1000 are
finally implemented. It would be good to consider NLLs as well before D is
committed. No point in repeating issues that have already been studied.
DIP25 waqs "finally
On 8/23/2018 6:32 AM, Steven Schveighoffer wrote:
Furthermore any member function (or UFCS function for that matter) REQUIRES the
first parameter to be the aggregate. How do you make a member function that
stuffs the return into a different parameter properly typecheck?
What I propose is that
On 8/23/2018 8:14 AM, Steven Schveighoffer wrote:
If I had to design a specific way to allow the common case to be easy, but still
provide a mechanism for the uncommon cases, I would say:
1. define a compiler-recognized attribute (e.g. @__sink).
2. If @__sink is applied to any parameter, that
On Friday, 24 August 2018 at 00:13:48 UTC, Mike Franklin wrote:
On Thursday, 23 August 2018 at 23:36:07 UTC, Chris M. wrote:
Heck, now that I'm looking at it, DIP25 seems like a more
restricted form of Rust's lifetimes. Let me know if I'm just
completely wrong about this, but
I think DIP 25
On Thursday, 23 August 2018 at 23:36:07 UTC, Chris M. wrote:
Heck, now that I'm looking at it, DIP25 seems like a more
restricted form of Rust's lifetimes. Let me know if I'm just
completely wrong about this, but
I think DIP 25 is analogous to Problem #3 for Rust's Non-Lexical
Lifetimes:
On Thursday, 23 August 2018 at 23:58:00 UTC, jmh530 wrote:
On Thursday, 23 August 2018 at 23:36:07 UTC, Chris M. wrote:
Heck, now that I'm looking at it, DIP25 seems like a more
restricted form of Rust's lifetimes. Let me know if I'm just
completely wrong about this, but
[snip]
Check out
On Thursday, 23 August 2018 at 23:36:07 UTC, Chris M. wrote:
Heck, now that I'm looking at it, DIP25 seems like a more
restricted form of Rust's lifetimes. Let me know if I'm just
completely wrong about this, but
[snip]
Check out DIP1000
On Thursday, 23 August 2018 at 15:48:00 UTC, Chris M. wrote:
On Thursday, 23 August 2018 at 15:14:07 UTC, Steven
Schveighoffer wrote:
On 8/23/18 9:32 AM, Steven Schveighoffer wrote:
[...]
Actually, thinking about this, the shortest lifetime is
dictated by how it is called, so there is no
On Thursday, 23 August 2018 at 15:14:07 UTC, Steven Schveighoffer
wrote:
On 8/23/18 9:32 AM, Steven Schveighoffer wrote:
[...]
Actually, thinking about this, the shortest lifetime is
dictated by how it is called, so there is no valid way to
determine which one makes sense when compiling the
On 8/23/18 9:32 AM, Steven Schveighoffer wrote:
On 8/23/18 4:58 AM, Walter Bright wrote:
On 8/22/2018 6:50 AM, Steven Schveighoffer wrote:
As for things being made "more flexible in the future" this basically
translates to code breakage. For example, if you are depending on
only the first
On 8/23/18 4:58 AM, Walter Bright wrote:
On 8/22/2018 6:50 AM, Steven Schveighoffer wrote:
What about:
size_t put(sink, parameters...)
Does this qualify as the sink being the "return" type? Obviously the
real return can't contain any references, so it trivially can be ruled
out as the
On Thursday, 23 August 2018 at 08:48:15 UTC, Walter Bright wrote:
On 8/22/2018 3:52 AM, Atila Neves wrote:
On Wednesday, 22 August 2018 at 09:05:13 UTC, Walter Bright
wrote:
On 8/21/2018 8:58 PM, Nicholas Wilson wrote:
On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves
wrote:
The problem
On Thursday, 23 August 2018 at 08:48:15 UTC, Walter Bright wrote:
Being a template doesn't make any difference, except that it
will helpfully infer these things.
Including the `return` attribute.
Also, since 'this' is passed by 'ref' to struct member
functions, it cannot escape anyway with
On 8/22/2018 6:50 AM, Steven Schveighoffer wrote:
What about:
size_t put(sink, parameters...)
Does this qualify as the sink being the "return" type? Obviously the real return
can't contain any references, so it trivially can be ruled out as the
destination of any escaping parameters.
Your
On 8/22/2018 3:52 AM, Atila Neves wrote:
On Wednesday, 22 August 2018 at 09:05:13 UTC, Walter Bright wrote:
On 8/21/2018 8:58 PM, Nicholas Wilson wrote:
On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote:
The problem is that the code we write doesn't deal directly with pointers -
On 8/22/18 5:23 AM, Walter Bright wrote:
On 8/21/2018 6:07 PM, Mike Franklin wrote:
The proposed idea wants to make the first parameter, if it's `ref`,
special.
This is because Phobos is written with functions of the form:
void put(sink, parameters...)
which corresponds to:
On Wednesday, 22 August 2018 at 11:02:00 UTC, Seb wrote:
No, it's behind a flag, so you can't really say that we're
shipping it as "production ready release".
The changes to Phobos are not behind a flag. We're making
changes to Phobos in the release branch to accommodate a
On Wednesday, 22 August 2018 at 02:18:15 UTC, Mike Franklin wrote:
On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin
wrote:
But what bothers me the most...
Something else that rubs me the wrong way is that DIP 1000 is
currently in a status of `DRAFT`:
On Wednesday, 22 August 2018 at 09:05:13 UTC, Walter Bright wrote:
On 8/21/2018 8:58 PM, Nicholas Wilson wrote:
On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote:
The problem is that the code we write doesn't deal directly
with pointers - see the recent confusion in this forum over
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:
dip1000 has been around for two years, and its predecessor
dip25 several years now. Plenty of time for anyone to comment
and/or propose something better.
Part of the problem is that the implementation keeps changing
without
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:
I want to ensure Atila is successful with this. But that means
Phobos has to compile with dip1000. So I need to make it work.
There's a good chance you'll get your PR merged when it's
documented and vetted, then you'll be
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:
The proposed idea wants to make the first parameter, if it's
`ref`, special.
This is because Phobos is written with functions of the form:
void put(sink, parameters...)
which corresponds to:
sink.put(parameters...)
On 8/21/2018 6:07 PM, Mike Franklin wrote:
The proposed idea wants to make the first parameter, if it's `ref`, special.
This is because Phobos is written with functions of the form:
void put(sink, parameters...)
which corresponds to:
sink.put(parameters...)
The two forms are fairly
On 8/21/2018 8:58 PM, Nicholas Wilson wrote:
On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote:
The problem is that the code we write doesn't deal directly with pointers -
see the recent confusion in this forum over where `scope` on the left applies
to the `this` pointer or the one
On 8/21/2018 2:17 PM, Atila Neves wrote:
Well, no. The syntax isn't the same for member functions. The examples from the
actual DIP don't compile. There it says:
---
scope can be applied to function return values (even though it is not a type
qualifier). It must be applied to the left of
On Wednesday, 22 August 2018 at 03:58:42 UTC, Nicholas Wilson
wrote:
On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote:
The problem is that the code we write doesn't deal directly
with pointers - see the recent confusion in this forum over
where `scope` on the left applies to the
On Wednesday, 22 August 2018 at 04:49:15 UTC, Mike Franklin wrote:
On Wednesday, 22 August 2018 at 04:23:52 UTC, Jonathan M Davis
wrote:
The reality of the matter is that the DIP system is a formal
way to propose language changes in order to convince Walter
and Andrei that those changes
On Wednesday, 22 August 2018 at 02:18:15 UTC, Mike Franklin wrote:
Something else that rubs me the wrong way is that DIP 1000 is
currently in a status of `DRAFT`:
https://github.com/dlang/DIPs/blob/master/DIPs/README.md
What the heck is going on here? We're adding features to the
compiler
On Wednesday, 22 August 2018 at 05:39:05 UTC, Mike Franklin wrote:
I understand that Walter's DIPs have been put through the
process just like the others, but with regard to the specific
issue in this thread
(https://issues.dlang.org/show_bug.cgi?id=19097), the
accompanying PR
On Wednesday, 22 August 2018 at 05:04:25 UTC, Mike Parker wrote:
Whatever the status of DIP 1000, I would point out that that
one of Walter's DIPs is in Community Review right now after
sitting in the PR queue in Draft Review for a while. Once this
review stage is done, it will go back into
On Wednesday, 22 August 2018 at 04:49:15 UTC, Mike Franklin wrote:
It is hypocritical an arrogant to believe that only our ideas
have flaws and require scrutiny.
Sorry, that was poorly stated and conveyed the wrong intent. It
should read:
It is hypocritical an arrogant to believe that
On Wednesday, 22 August 2018 at 02:18:15 UTC, Mike Franklin wrote:
Furthermore, I find it hypocritical that some of us are put
through a disproportionately burdensome DIP process requiring
thorough documentation, multiple peer reviews, excessive
delays, and judgement that defaults to "no" for
On Wednesday, 22 August 2018 at 04:23:52 UTC, Jonathan M Davis
wrote:
The reality of the matter is that the DIP system is a formal
way to propose language changes in order to convince Walter and
Andrei that those changes should be implemented, whereas if
Walter or Andrei writes the DIP,
On Tuesday, August 21, 2018 8:18:15 PM MDT Mike Franklin via Digitalmars-d
wrote:
> On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin wrote:
> > But what bothers me the most...
>
> Something else that rubs me the wrong way is that DIP 1000 is
> currently in a status of `DRAFT`:
>
On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote:
The problem is that the code we write doesn't deal directly
with pointers - see the recent confusion in this forum over
where `scope` on the left applies to the `this` pointer or the
one returned by the member function.
Kagamin
On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin wrote:
But what bothers me the most...
Something else that rubs me the wrong way is that DIP 1000 is
currently in a status of `DRAFT`:
https://github.com/dlang/DIPs/blob/master/DIPs/README.md
What the heck is going on here?
On Tuesday, 21 August 2018 at 21:17:25 UTC, Atila Neves wrote:
I don't have merge rights. I took a look anyway and it mostly
looks ok, but I'm not familiar enough with that part of the
codebase.
It's not the implementation that's preventing it from being
merged. It's the idea itself, weak
On Tuesday, 21 August 2018 at 19:36:39 UTC, Walter Bright wrote:
On 8/21/2018 7:31 AM, Atila Neves wrote:
The problem is that the code we write doesn't deal directly
with pointers - see the recent confusion in this forum over
where `scope` on the left applies to the `this` pointer or the
one
On 8/21/2018 7:31 AM, Atila Neves wrote:
The problem is that the code we write doesn't deal directly with pointers - see
the recent confusion in this forum over where `scope` on the left applies to the
`this` pointer or the one returned by the member function.
That's what I was saying :-)
On Tuesday, 21 August 2018 at 00:09:03 UTC, Walter Bright wrote:
On 8/20/2018 6:46 AM, Steven Schveighoffer wrote:
I would, but I have no idea how dip1000 is supposed to work. I
think only you understand it. Even looking at the PR that you
have been citing over and over, I can't make heads or
On 8/20/2018 6:46 AM, Steven Schveighoffer wrote:
I would, but I have no idea how dip1000 is supposed to work. I think only you
understand it. Even looking at the PR that you have been citing over and over, I
can't make heads or tails of what it does or what it allows.
The way to understand
On 8/20/2018 6:08 AM, Atila Neves wrote:
As mentioned in my other thread, I went to file one and it was declared not a
bug:
https://issues.dlang.org/show_bug.cgi?id=17927
I'll look at it again.
On Monday, August 20, 2018 7:46:48 AM MDT Steven Schveighoffer via
Digitalmars-d wrote:
> I would, but I have no idea how dip1000 is supposed to work. I think
> only you understand it. Even looking at the PR that you have been citing
> over and over, I can't make heads or tails of what it does or
On 8/17/18 11:04 PM, Walter Bright wrote:
On 8/17/2018 11:17 AM, bachmeier wrote:
This is a good example of D needing to evolve or fizzle out. I don't
see evidence that the community has yet figured out how to evolve the
language. If it had, these problems would not be around for so many
On Saturday, 18 August 2018 at 02:17:01 UTC, Walter Bright wrote:
On 8/17/2018 4:33 AM, Atila Neves wrote:
I've been using -dip1000 a lot lately.
Great news!
:)
I hit two bugs yesterday.
In D? or in your code?
In dmd.
Bugs don't count if they're not in bugzilla!
As mentioned in
On 8/17/2018 5:30 AM, Atila Neves wrote:
It's not easy though. You have to either be building your own phobos
Not really. You only have to be able to import phobos files. You don't have to
compile something that will link.
I.e. just copy the phobos source tree, add @safe to it, and point
On 8/17/2018 11:17 AM, bachmeier wrote:
This is a good example of D needing to evolve or fizzle out. I don't see
evidence that the community has yet figured out how to evolve the language. If
it had, these problems would not be around for so many years.
We deprecate features of D all the
On 8/17/2018 4:33 AM, Atila Neves wrote:
I've been using -dip1000 a lot lately.
Great news!
I hit two bugs yesterday.
In D? or in your code?
When it works, it's great, _except_:
. @safe isn't default
. -dip1000 isn't default
. Good luck figuring out why your template functions aren't
On 8/17/2018 3:01 AM, Jonathan M Davis wrote:
we still don't have a real plan as to how we're going to make
-dip1000 the default.
We do have a plan. Get Phobos to compile with -dip1000. As to why that hasn't
happened yet, see:
https://github.com/dlang/dmd/pull/8504
On 8/17/2018 12:50 AM, Jonathan M Davis wrote:
> That particular bug is a duplicate of
> https://issues.dlang.org/show_bug.cgi?id=8838, which was closed as fixed
> based on the fact that -dip1000 fixes the problem by treating marking the
> slice of a static array with scope. It's still quite
On Friday, 17 August 2018 at 16:00:26 UTC, 12345swordy wrote:
On Friday, 17 August 2018 at 15:27:22 UTC, Mike Franklin wrote:
I actually started writing a DIP for this about a year ago,
but I need to pick my battles.
Mike
Is it on github?
Alex
No,but here are some notes I found in my
On Friday, 17 August 2018 at 17:59:45 UTC, H. S. Teoh wrote:
As opposed to today's situation, where somebody tries something
illegal and the compiler fails to detect it, and nobody even
know there's a problem until it becomes an exploitable bug that
causes a security problem. Given today's
On Fri, Aug 17, 2018 at 05:26:48PM +, jmh530 via Digitalmars-d wrote:
> On Friday, 17 August 2018 at 14:26:07 UTC, H. S. Teoh wrote:
> > [...]
> > And that is exactly why the whole implementation of @safe is
> > currently rather laughable. By blacklisting rather than
> > whitelisting, we
On 8/17/18 1:26 PM, jmh530 wrote:
On Friday, 17 August 2018 at 14:26:07 UTC, H. S. Teoh wrote:
[...]
And that is exactly why the whole implementation of @safe is currently
rather laughable. By blacklisting rather than whitelisting, we
basically open the door wide open to loopholes --
On Friday, 17 August 2018 at 14:26:07 UTC, H. S. Teoh wrote:
[...]
And that is exactly why the whole implementation of @safe is
currently rather laughable. By blacklisting rather than
whitelisting, we basically open the door wide open to loopholes
-- anything that we haven't thought of yet
On Friday, 17 August 2018 at 15:27:22 UTC, Mike Franklin wrote:
I actually started writing a DIP for this about a year ago, but
I need to pick my battles.
Mike
Is it on github?
Alex
On Friday, 17 August 2018 at 14:26:07 UTC, H. S. Teoh wrote:
On Fri, Aug 17, 2018 at 01:50:32AM -0600, Jonathan M Davis via
Digitalmars-d wrote: [...]
Honestly, the reality of the matter is that @safe is probably
always going to be somewhat broken, because it's implemented
via blacklisting
On 8/17/18 7:26 AM, H. S. Teoh wrote:
It will continue to be a problem as long as @safe is implemented via
blacklisting, because every single time there's a new language feature,
there's a chance that a loophole is introduced into @safe. And that's
not counting the combinatorial explosion of
On Fri, Aug 17, 2018 at 01:50:32AM -0600, Jonathan M Davis via Digitalmars-d
wrote:
[...]
> Honestly, the reality of the matter is that @safe is probably always
> going to be somewhat broken, because it's implemented via blacklisting
> rather than whitelisting. Instead of @safe only allowing
On 18/08/2018 1:29 AM, vit wrote:
On Friday, 17 August 2018 at 13:02:20 UTC, Jonathan M Davis wrote:
On Friday, August 17, 2018 6:30:26 AM MDT Atila Neves via
Digitalmars-d wrote:
On Friday, 17 August 2018 at 11:37:54 UTC, rikki cattermole wrote:
> On 17/08/2018 11:33 PM, Atila Neves wrote:
>>
On Friday, 17 August 2018 at 13:02:20 UTC, Jonathan M Davis wrote:
On Friday, August 17, 2018 6:30:26 AM MDT Atila Neves via
Digitalmars-d wrote:
On Friday, 17 August 2018 at 11:37:54 UTC, rikki cattermole
wrote:
> On 17/08/2018 11:33 PM, Atila Neves wrote:
>> . Good luck figuring out why your
On Friday, August 17, 2018 6:30:26 AM MDT Atila Neves via Digitalmars-d
wrote:
> On Friday, 17 August 2018 at 11:37:54 UTC, rikki cattermole wrote:
> > On 17/08/2018 11:33 PM, Atila Neves wrote:
> >> . Good luck figuring out why your template functions aren't
> >> @safe and coaxing the compiler
On Friday, 17 August 2018 at 11:37:54 UTC, rikki cattermole wrote:
On 17/08/2018 11:33 PM, Atila Neves wrote:
. Good luck figuring out why your template functions aren't
@safe and coaxing the compiler to tell you why it's inferring
the attributes it is. Bonus points if it's a Phobos function
On 17/08/2018 11:33 PM, Atila Neves wrote:
. Good luck figuring out why your template functions aren't @safe and
coaxing the compiler to tell you why it's inferring the attributes it
is. Bonus points if it's a Phobos function so you can't slap `@safe` on
its definition.
Sure you can. It's a
On Friday, 17 August 2018 at 08:23:20 UTC, vit wrote:
On Friday, 17 August 2018 at 07:50:32 UTC, Jonathan M Davis
wrote:
On Friday, August 17, 2018 1:19:25 AM MDT Peter Alexander via
Digitalmars-d wrote:
[...]
That particular bug is a duplicate of
On Friday, August 17, 2018 2:23:20 AM MDT vit via Digitalmars-d wrote:
> On Friday, 17 August 2018 at 07:50:32 UTC, Jonathan M Davis wrote:
> > On Friday, August 17, 2018 1:19:25 AM MDT Peter Alexander via
> >
> > Digitalmars-d wrote:
> >> [...]
> >
> > That particular bug is a duplicate of
> >
On Friday, 17 August 2018 at 07:50:32 UTC, Jonathan M Davis wrote:
On Friday, August 17, 2018 1:19:25 AM MDT Peter Alexander via
Digitalmars-d wrote:
[...]
That particular bug is a duplicate of
https://issues.dlang.org/show_bug.cgi?id=8838, which was closed
as fixed based on the fact that
On Friday, 17 August 2018 at 07:50:32 UTC, Jonathan M Davis wrote:
That particular bug is a duplicate of
https://issues.dlang.org/show_bug.cgi?id=8838, which was closed
as fixed based on the fact that -dip1000 fixes the problem by
treating marking the slice of a static array with scope. It's
On Friday, August 17, 2018 1:19:25 AM MDT Peter Alexander via Digitalmars-d
wrote:
>
> import std.algorithm, std.stdio;
>
> @safe:
>
> auto foo() {
>int[6] xs = [0, 1, 2, 3, 4, 5];
>return xs[].map!(x => x);
> }
>
> void main() {
>writeln(foo());
> }
>
>
>
import std.algorithm, std.stdio;
@safe:
auto foo() {
int[6] xs = [0, 1, 2, 3, 4, 5];
return xs[].map!(x => x);
}
void main() {
writeln(foo());
}
https://run.dlang.io/is/qC7HUR
For me this gives:
[0, 0, -2132056872, 22008, 0, 0]
Which looks like its
85 matches
Mail list logo
