Re: DIP1000: Scoped Pointers
On 17 Aug 2016 04:00, "Mike via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Wednesday, 17 August 2016 at 01:42:00 UTC, Walter Bright wrote:
>
>>> Can you please clarify the current implementation `scope`, and what
DIP1000
>>> proposes to change with respect to the current implementation?
>>
>>
>> It just adds to the existing compiler implementation of 'scope'. It has
nothing to do with std.typecons.scoped.
>
>
> Ok, but the deprecations page [1] gives this example...
>
> class A
> {
> int x;
> this(int x) { this.x = x; }
> }
>
> void main()
> {
> A obj;
> {
> scope A a = new A(1);
> obj = a;
> }
> assert(obj.x == 1); // fails, 'a' has been destroyed
> }
>
> ... as a deprecated pattern, and corrected with ...
>
> class A
> {
> this(int x) { }
> }
> void main()
> {
> auto a = std.typecons.scoped!A(1);
> }
>
> However, in DIP1000, the examples use the above deprecated pattern
extensively. So what's the story? Does the deprecations page [1] need an
update?
>
> [1]
http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack
Basically DIP1000 makes it so that:
> void main()
> {
> A obj;
> {
> scope A a = new A(1);
> obj = a;
> }
> assert(obj.x == 1); // fails, 'a' has been destroyed
> }
Will not compile.
Re: DIP1000: Scoped Pointers
On Wednesday, 17 August 2016 at 01:42:00 UTC, Walter Bright wrote:
Can you please clarify the current implementation `scope`, and
what DIP1000
proposes to change with respect to the current implementation?
It just adds to the existing compiler implementation of
'scope'. It has nothing to do with std.typecons.scoped.
Ok, but the deprecations page [1] gives this example...
class A
{
int x;
this(int x) { this.x = x; }
}
void main()
{
A obj;
{
scope A a = new A(1);
obj = a;
}
assert(obj.x == 1); // fails, 'a' has been destroyed
}
... as a deprecated pattern, and corrected with ...
class A
{
this(int x) { }
}
void main()
{
auto a = std.typecons.scoped!A(1);
}
However, in DIP1000, the examples use the above deprecated
pattern extensively. So what's the story? Does the deprecations
page [1] need an update?
[1]
http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack
Re: DIP1000: Scoped Pointers
On 8/16/2016 6:01 PM, H. S. Teoh via Digitalmars-d-announce wrote: On Wed, Aug 17, 2016 at 01:01:05AM +, Chris Wright via Digitalmars-d-announce wrote: On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote: You need to add one more level of indirection for things to start going complicated. Presumably scope is transitive, so things shouldn't get horribly complex. I thought the DIP states the scope is *not* transitive? It is not transitive.
Re: DIP1000: Scoped Pointers
On 8/16/2016 5:31 PM, Mike wrote: On Monday, 15 August 2016 at 04:58:06 UTC, Walter Bright wrote: On 8/14/2016 9:56 PM, Joseph Rushton Wakeling wrote: Does that actually work in D2? Yes. Can you please clarify the current implementation `scope`, and what DIP1000 proposes to change with respect to the current implementation? It just adds to the existing compiler implementation of 'scope'. It has nothing to do with std.typecons.scoped.
Re: DIP1000: Scoped Pointers
On Wed, Aug 17, 2016 at 01:01:05AM +, Chris Wright via Digitalmars-d-announce wrote: > On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote: > > You need to add one more level of indirection for things to start > > going complicated. > > Presumably scope is transitive, so things shouldn't get horribly > complex. I thought the DIP states the scope is *not* transitive? T -- The right half of the brain controls the left half of the body. This means that only left-handed people are in their right mind. -- Manoj Srivastava
Re: DIP1000: Scoped Pointers
On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote: > You need to add one more level of indirection for things to start going > complicated. Presumably scope is transitive, so things shouldn't get horribly complex.
Re: DIP1000: Scoped Pointers
On Monday, 15 August 2016 at 04:58:06 UTC, Walter Bright wrote: On 8/14/2016 9:56 PM, Joseph Rushton Wakeling wrote: Does that actually work in D2? Yes. Can you please clarify the current implementation `scope`, and what DIP1000 proposes to change with respect to the current implementation? According to this [http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack] it was deprecated in favor of std.typecons.scoped. But your previous statement say's scoped variables is still a thing. What exactly is being deprecated with regard to `scope`, if anything? Does the deprecated features page need an update? Will DIP1000 render `std.typecons.scoped` obsolete? In other words, does DIP1000 deprecate the deprecation? Is `scope` being repurposed for DIP1000, or simply expanded? In other words does DIP1000 change the current implementation of scope in any way, or just add to it? Thanks, Mike
Re: DIP1000: Scoped Pointers
On 8/16/2016 11:25 AM, Meta wrote:
What about this?
struct Rnd
{
int* state;
}
void test()
{
scope rnd = new Rnd();
Rnd rnd2 = *rnd;
saveGlobalState(rnd2);
}
'state' is set to null by 'new Rnd()', and so no pointers escape.
Re: Aedi - a dependency injection library
On 16 Aug 2016 20:45, "Alexandru Ermicioi via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg wrote: >> >> On 2016-08-16 11:41, Alexandru Ermicioi wrote: >> >>> https://github.com/aermicioi/aedi >> >> >> If you use: >> >> ```d >> ``` >> >> For the code block you'll get syntax highlighting for D. > > > Thx, for info. Didn't know about such syntax. I'll update it with next batch of modifications. Can this be used to do function currying? http://stackoverflow.com/questions/36314/what-is-currying Seems like an interesting feature. I imagine it would use templates or a wrapper struct instead of wrapped functions though.
Re: DIP1000: Scoped Pointers
On 16 Aug 2016 21:01, "Dicebot via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, 16 August 2016 at 18:55:40 UTC, Dicebot wrote:
>>
>> On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote:
>>>
>>> What about this?
>>>
>>> struct Rnd
>>> {
>>> int* state;
>>> }
>>>
>>> void test()
>>> {
>>> scope rnd = new Rnd();
>>> Rnd rnd2 = *rnd;
>>>
>>> saveGlobalState(rnd2);
>>> }
>>
>>
>> Same as far as I understand, because "from a lifetime analysis
viewpoint, a struct is considered a juxtaposition of its direct members" (
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#aggregates). You
need to add one more level of indirection for things to start going
complicated.
>
>
> Ah no, sorry, I have missed that you allocate struct on heap. Yes, this
is simplified problem case indeed. Intention is that such struct can be
made @safe by making all pointer fields private and adding scope semantics
in getter methods but it is hard to reason about details at this point.
It will be nice to see a set of tests that are expected to pass, a set that
are expected to fail, and a set that segfault.
In my questions I was trying to make small examples, that could become
tests.
The examples in the DIP are quite simple actually. The pointer escaping
example is what I was missing.
Re: DIP1000: Scoped Pointers
On Tuesday, 16 August 2016 at 18:55:40 UTC, Dicebot wrote:
On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote:
What about this?
struct Rnd
{
int* state;
}
void test()
{
scope rnd = new Rnd();
Rnd rnd2 = *rnd;
saveGlobalState(rnd2);
}
Same as far as I understand, because "from a lifetime analysis
viewpoint, a struct is considered a juxtaposition of its direct
members"
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#aggregates). You need to add one more level of indirection for things to start going complicated.
Ah no, sorry, I have missed that you allocate struct on heap.
Yes, this is simplified problem case indeed. Intention is that
such struct can be made @safe by making all pointer fields
private and adding scope semantics in getter methods but it is
hard to reason about details at this point.
Re: DIP1000: Scoped Pointers
On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote:
What about this?
struct Rnd
{
int* state;
}
void test()
{
scope rnd = new Rnd();
Rnd rnd2 = *rnd;
saveGlobalState(rnd2);
}
Same as far as I understand, because "from a lifetime analysis
viewpoint, a struct is considered a juxtaposition of its direct
members"
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#aggregates). You need to add one more level of indirection for things to start going complicated.
Re: Aedi - a dependency injection library
On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg wrote: On 2016-08-16 11:41, Alexandru Ermicioi wrote: https://github.com/aermicioi/aedi If you use: ```d ``` For the code block you'll get syntax highlighting for D. Thx, for info. Didn't know about such syntax. I'll update it with next batch of modifications.
Re: DIP1000: Scoped Pointers
On Tuesday, 16 August 2016 at 16:34:05 UTC, Dicebot wrote:
On 08/16/2016 07:26 PM, Patrick Schluter wrote:
What happens in that case ?
void test() {
scope rnd = new Rnd; // reference semantic and stack allocated
Rnd rnd2;
rnd2 = rnd;
some_sneaky_function_that_saves_global_state(rnd);
}
or is that not even possible ? (sorry I'm still a noob in D).
If `Rnd` is supposed to be a class, it won't compile because it
would
mean escaping scope reference to non-scope variable (with
DIP1000). If
it is a struct, it won't compile because you are trying to
assign `Rnd*`
(pointer) to `Rnd` (value) :)
What about this?
struct Rnd
{
int* state;
}
void test()
{
scope rnd = new Rnd();
Rnd rnd2 = *rnd;
saveGlobalState(rnd2);
}
Re: DIP1000: Scoped Pointers
On 08/16/2016 07:26 PM, Patrick Schluter wrote:
> What happens in that case ?
>
> void test() {
> scope rnd = new Rnd; // reference semantic and stack allocated
> Rnd rnd2;
> rnd2 = rnd;
> some_sneaky_function_that_saves_global_state(rnd);
> }
>
> or is that not even possible ? (sorry I'm still a noob in D).
If `Rnd` is supposed to be a class, it won't compile because it would
mean escaping scope reference to non-scope variable (with DIP1000). If
it is a struct, it won't compile because you are trying to assign `Rnd*`
(pointer) to `Rnd` (value) :)
signature.asc
Description: OpenPGP digital signature
Re: DIP1000: Scoped Pointers
On Monday, 15 August 2016 at 21:25:22 UTC, Walter Bright wrote:
On 8/15/2016 6:54 AM, Rory McGuire via Digitalmars-d-announce
wrote:
okay nice, so that code would not compile but code such as:
void test() {
scope rnd = new Rnd; // reference semantic and stack allocated
auto rnd2 = rnd;
some_sneaky_function_that_saves_global_state(rnd);
}
would still not be checked. And would crash inexplicably at
the point the global
was accessed?
A local variable initialized with a scoped value will have
'scope' inferred for it.
What happens in that case ?
void test() {
scope rnd = new Rnd; // reference semantic and stack allocated
Rnd rnd2;
rnd2 = rnd;
some_sneaky_function_that_saves_global_state(rnd);
}
or is that not even possible ? (sorry I'm still a noob in D).
Re: Aedi - a dependency injection library
On 2016-08-16 11:41, Alexandru Ermicioi wrote: https://github.com/aermicioi/aedi If you use: ```d ``` For the code block you'll get syntax highlighting for D. -- /Jacob Carlborg
Aedi - a dependency injection library
Good day. I'd like to show my library aedi (v0.0.1), which implements dependency injection pattern. They key features of aedi are: 1) Simple api through which a container can be configured with objects. 2) Ability to extend the library with custom logic required by your code. 3) Ability to inject already instantiated data (not only objects). 4) Possibility to build a hierarchy of containers that will be used to resolve dependencies. (for ex. if there is a need of a container that ships prototype objects along with singleton ones). For more information about common usage of library, check readme.md on github. Most of library is documented (functions, classes, interfaces, etc.). If there is some unclarity in docs, please tell about it. https://github.com/aermicioi/aedi https://github.com/aermicioi/aedi/blob/master/readme.md The library is still in development, and I'd like to see some comments, on library's usability, as well possible improvements of it. Thank you.
