www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Release D 2.073.0

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
Glad to announce D 2.073.0.

This release comes with a few phobos additions, new -mcpu=avx and -mscrt
switch, and several bugfixes.

http://dlang.org/download.html
http://dlang.org/changelog/2.073.0.html

-Martin
Jan 22 2017
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Sunday, 22 January 2017 at 17:55:03 UTC, Martin Nowak wrote:

 Glad to announce D 2.073.0.

 This release comes with a few phobos additions, new -mcpu=avx 
 and -mscrt switch, and several bugfixes.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.073.0.html

 -Martin


Thanks for this release and especially for having handled the new 
regressions.
Jan 22 2017
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
On Sunday, 22 January 2017 at 17:55:03 UTC, Martin Nowak wrote:

 Glad to announce D 2.073.0.

 This release comes with a few phobos additions, new -mcpu=avx 
 and -mscrt switch, and several bugfixes.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.073.0.html

 -Martin


<3
Jan 24 2017
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 22 January 2017 at 17:55:03 UTC, Martin Nowak wrote:

 Glad to announce D 2.073.0.

 This release comes with a few phobos additions, new -mcpu=avx 
 and -mscrt switch, and several bugfixes.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.073.0.html

 -Martin


Thank you!
Jan 25 2017
prev sibling next sibling parent evilrat <evilrat666 gmail.com> writes:
On Sunday, 22 January 2017 at 17:55:03 UTC, Martin Nowak wrote:

 Glad to announce D 2.073.0.

 This release comes with a few phobos additions, new -mcpu=avx 
 and -mscrt switch, and several bugfixes.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.073.0.html

 -Martin


Can we have some love for Windows COM and extern C++ ABI 
regarding return struct by value for next release, please?

I mean there is already few bug reports[1,2] on that matter. For 
example when return struct with 2 floats first one goes to ECX, 
second to EDX, DMD got only the second one. In x64 it is even 
worse, in most cases it just crashes. And LDC crashes in both 
x86/x64, so... can't use D at all.

It is a real blocker which prevents from using D in some areas, 
like DirectX (for example Direct2D is what used to make fast and 
effecient 2d rendering for UI, sure this is not the only way but 
it is native!)

there was also a thread not so long ago - 
http://forum.dlang.org/post/tiyttpodenppvlfxixcw forum.dlang.org

[1] https://issues.dlang.org/show_bug.cgi?id=16987
[2] https://issues.dlang.org/show_bug.cgi?id=16527
Jan 25 2017
prev sibling parent reply Dicebot <public dicebot.lv> writes:
https://issues.dlang.org/show_bug.cgi?id=17123

Can I have my "I told you so" badge please?
Jan 26 2017
next sibling parent reply Dicebot <public dicebot.lv> writes:
And also stuff like https://github.com/dlang/druntime/pull/1740 - 
I think the story behind `return scope` is the critical point for 
me. It is worst technical disaster that has happened to compiler 
in years, and I am going to blame Walter personally for it.
Jan 27 2017
next sibling parent Kagamin <spam here.lot> writes:
On Friday, 27 January 2017 at 11:12:22 UTC, Dicebot wrote:

 And also stuff like https://github.com/dlang/druntime/pull/1740


Why it would break code if `in` meant `scope`?
Jan 27 2017
prev sibling next sibling parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 27 January 2017 at 11:12:22 UTC, Dicebot wrote:

 And also stuff like https://github.com/dlang/druntime/pull/1740 
 - I think the story behind `return scope` is the critical point 
 for me. It is worst technical disaster that has happened to 
 compiler in years, and I am going to blame Walter personally 
 for it.


So what would the alternative be?
Jan 27 2017
parent Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: Release D 2.073.0
References: <o62rml$mju$1 digitalmars.com>
 <ijphznsbxvukmwpybgll forum.dlang.org> <oxsmdsycgpehnefcqdsv forum.dlang.org>
 <fvwobfnojquffnnkrrzz forum.dlang.org>
In-Reply-To: <fvwobfnojquffnnkrrzz forum.dlang.org>

--QBIoTH8KPuxjThDlWph9aWvpDHCtKvWoK
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 01/27/2017 01:29 PM, Nordl=C3=B6w wrote:

 On Friday, 27 January 2017 at 11:12:22 UTC, Dicebot wrote:

 And also stuff like https://github.com/dlang/druntime/pull/1740 - I
 think the story behind `return scope` is the critical point for me. It=





 is worst technical disaster that has happened to compiler in years,
 and I am going to blame Walter personally for it.


=20
 So what would the alternative be?


Alternative would be to implement new functionality like a responsible
developer - keep it in sync with specification document, design set of
acceptance tests and do all the development in a separate branch until
is verified to both have desired semantics and don't cause any breakage
in existing projects. And don't rush into forcing usage of half-done
feature inside standard library the very moment it got released.


--QBIoTH8KPuxjThDlWph9aWvpDHCtKvWoK--
Jan 27 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/27/2017 3:12 AM, Dicebot wrote:

 And also stuff like https://github.com/dlang/druntime/pull/1740


I'm curious what is wrong with that?



 I think the
 story behind `return scope` is the critical point for me. It is worst technical
 disaster that has happened to compiler in years, and I am going to blame Walter
 personally for it.


Yes, I'm 100% responsible for 'return scope' and pushing it harder than most 
people probably would like. Maybe I'm alone, but I strongly believe it is 
critical to D's future.
Jan 27 2017
next sibling parent deadalnix <deadalnix gmail.com> writes:
On Friday, 27 January 2017 at 19:12:37 UTC, Walter Bright wrote:

 Yes, I'm 100% responsible for 'return scope' and pushing it 
 harder than most people probably would like. Maybe I'm alone, 
 but I strongly believe it is critical to D's future.


You sound like this guy: 
http://www.drdobbs.com/cpp/type-qualifiers-and-wild-cards/231902461
Jan 27 2017
prev sibling parent reply Dicebot <public dicebot.lv> writes:
On Friday, 27 January 2017 at 19:12:37 UTC, Walter Bright wrote:

 On 1/27/2017 3:12 AM, Dicebot wrote:

 And also stuff like https://github.com/dlang/druntime/pull/1740


 I'm curious what is wrong with that?


You have been pushing for premature merged of `return scope` 
under a premise that it will be hidden behind a switch and won't 
affect anyone yet. Now you rush to adjust druntime to use it and 
require the same from any druntime contributors.
Jan 29 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2017 4:18 AM, Dicebot wrote:

 On Friday, 27 January 2017 at 19:12:37 UTC, Walter Bright wrote:

 On 1/27/2017 3:12 AM, Dicebot wrote:

 And also stuff like https://github.com/dlang/druntime/pull/1740


 I'm curious what is wrong with that?


 You have been pushing for premature merged of `return scope` under a premise
 that it will be hidden behind a switch and won't affect anyone yet. Now you
rush
 to adjust druntime to use it


Drilling down in Phobos to make it work with -dip1000, at the bottom are
usually 
calls to core.stdc.*. Without annotating those functions, all progress on 
-dip1000 comes to a halt.

-dip1000 is designed so that non-dip1000 code can call dip1000 code. Adding 
these annotations should be benign to existing code. Nothing failed after
adding 
these annotations, either in Phobos which is not (yet) dip1000, nor any of the 
projects tested, nor any of the test suite.


 and require the same from any druntime contributors.


Since druntime is now compiled with -dip1000, and future druntime contributions 
are not existing code, that is a reasonable expectation.

On the same premise, I am working to get Phobos compatible with -dip1000. 
Without that compatibility, -dip1000 is pretty much unusable.

----

It's analogous to druntime and phobos being officially compiled with -dip25, 
which has been the case for some time now.
Jan 29 2017
parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,a,n,n,o,u,n,c,e
Subject: Re: Release D 2.073.0
References: <o62rml$mju$1 digitalmars.com>
 <ijphznsbxvukmwpybgll forum.dlang.org> <oxsmdsycgpehnefcqdsv forum.dlang.org>
 <o6g62p$cm7$1 digitalmars.com> <bpdjdfyvwlfdrrgtewyk forum.dlang.org>
 <o6m1tc$1kch$1 digitalmars.com>
In-Reply-To: <o6m1tc$1kch$1 digitalmars.com>

--qHnIAdrtC7cKC0SAgob6PIfuHIQedfcAR
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 01/30/2017 12:38 AM, Walter Bright wrote:

 ...


Please, don't waste your time. You mentioned being curious about what is
wrong with that PR - I have explained. Let's just stop here before you
write another 20 posts presuming that I only disagree with your
development methodology because I don't understand it.


--qHnIAdrtC7cKC0SAgob6PIfuHIQedfcAR--
Jan 29 2017
next sibling parent reply ilya-stromberg <ilya-stromberg-2009 yandex.ru> writes:
On Monday, 30 January 2017 at 01:15:52 UTC, Dicebot wrote:

 On 01/30/2017 12:38 AM, Walter Bright wrote:

 ...


 Please, don't waste your time. You mentioned being curious 
 about what is wrong with that PR - I have explained. Let's just 
 stop here before you write another 20 posts presuming that I 
 only disagree with your development methodology because I don't 
 understand it.


Walter created an entire language and a community around it. Can 
you, please, share with us how your accomplishments give any 
importance to whatever your disagreement is with him? All that is 
visible, here is you protest everything, take any opportunity to 
verbally abuse everyone and make no contribution.

Thanks.
Jan 29 2017
parent deadalnix <deadalnix gmail.com> writes:
On Monday, 30 January 2017 at 01:34:52 UTC, ilya-stromberg wrote:

 Walter created an entire language and a community around it. 
 Can you, please, share with us how your accomplishments give 
 any importance to whatever your disagreement is with him? All 
 that is visible, here is you protest everything, take any 
 opportunity to verbally abuse everyone and make no contribution.

 Thanks.


No because you are making an argument from authority and are 
asking to replied by another argument from authority, which bring 
0 value to anyone.
Jan 30 2017
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Monday, 30 January 2017 at 01:15:52 UTC, Dicebot wrote:

 On 01/30/2017 12:38 AM, Walter Bright wrote:

 ...


 Please, don't waste your time. You mentioned being curious 
 about what is wrong with that PR - I have explained. Let's just 
 stop here before you write another 20 posts presuming that I 
 only disagree with your development methodology because I don't 
 understand it.


I hope it puts some light on why I abandoned the DIP process.
Jan 30 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2017 5:42 AM, Dicebot wrote:

 https://issues.dlang.org/show_bug.cgi?id=17123

 Can I have my "I told you so" badge please?


Yes, you may. But nobody promised there would be no regressions - just that 
we'll fix them. I'll see about taking care of this one. Thanks for reporting it.
Jan 27 2017
parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 27 January 2017 at 19:09:30 UTC, Walter Bright wrote:

 On 1/26/2017 5:42 AM, Dicebot wrote:

 https://issues.dlang.org/show_bug.cgi?id=17123

 Can I have my "I told you so" badge please?


 Yes, you may. But nobody promised there would be no regressions 
 - just that we'll fix them. I'll see about taking care of this 
 one. Thanks for reporting it.


Regressions are the symptoms.

I mostly went silent on this because I this point, I have no idea 
how to reach to you and Andrei. This is bad because of all the 
same reasons inout is bad, plus some other on its own, and is 
going down exactly like inout so far, plus some extra problems on 
its own.
Jan 27 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/27/2017 4:43 PM, deadalnix wrote:

 I mostly went silent on this because I this point, I have no idea how to reach
 to you and Andrei. This is bad because of all the same reasons inout is bad,
 plus some other on its own, and is going down exactly like inout so far, plus
 some extra problems on its own.



If you've got a case, make it. If you see problems, explain. If you want to 
help, please do.
Jan 27 2017
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 28 January 2017 at 03:40:43 UTC, Walter Bright wrote:

 On 1/27/2017 4:43 PM, deadalnix wrote:

 I mostly went silent on this because I this point, I have no 
 idea how to reach
 to you and Andrei. This is bad because of all the same reasons 
 inout is bad,
 plus some other on its own, and is going down exactly like 
 inout so far, plus
 some extra problems on its own.



 If you've got a case, make it. If you see problems, explain. If 
 you want to help, please do.


I did so repeatedly for years and never reached to you or Andrei, 
so I'm not sure how that's going to change anything but here you 
go.

The root problem you are trying to solve is to be able to specify 
that what comes out of a function has a common property with what 
come in. In the case of inout, this property is the type 
qualifier, in the case of return/scope this is the lifetime.

Same problem, same solution, same fallout.
Jan 28 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/28/2017 3:51 AM, deadalnix wrote:

 I did so repeatedly for years and never reached to you or Andrei, so I'm not
 sure how that's going to change anything but here you go.


By being specific.



 The root problem you are trying to solve is to be able to specify that what
 comes out of a function has a common property with what come in. In the case of
 inout, this property is the type qualifier, in the case of return/scope this is
 the lifetime.


Yup.



 Same problem, same solution, same fallout.


What problem?
Jan 28 2017
parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 28 January 2017 at 21:46:17 UTC, Walter Bright wrote:

 Same problem, same solution, same fallout.


 What problem?


Ask Andrei, he asked for inout's deprecation. I'm not going to 
run after you two like you are toddlers. Having to make the same 
case again and again for literally years is not something I wish 
to take part in. That case has been made. Get up to date or 
delegate.
Jan 30 2017
parent Nestor <nestorperez2016 yopmail.com> writes:
Just a quick unrelated words:
Shouldn't copyright be updated too?

D:\>dmd --version
DMD32 D Compiler v2.073.0
Copyright (c) 1999-2016 by Digital Mars written by Walter Bright
Jan 30 2017
prev sibling next sibling parent pineapple <meapineapple gmail.com> writes:
On Saturday, 28 January 2017 at 03:40:43 UTC, Walter Bright wrote:

 If you've got a case, make it. If you see problems, explain. If 
 you want to help, please do.


So, do what numerous people have done numerous times already, to 
no great effect?
Jan 28 2017
prev sibling parent reply Olivier FAURE <olivier.faure epitech.eu> writes:
On Saturday, 28 January 2017 at 03:40:43 UTC, Walter Bright wrote:

 If you've got a case, make it. If you see problems, explain. If 
 you want to help, please do.


For what it's worth, here are my problems with 'return scope':

- As far as I can tell, it's not properly documented. The github 
page for DIP-1000 is apparently pending a rewrite, and I can't 
find a formal definition of 'return scope' anywhere (the D 
reference 'Functions' page only mentions 'return ref', and in 
passing).

- I personally don't like using the return keyword as anything 
but an instruction; when I'm reading code, I can have a good 
feeling of the code's flow by just looking at the indentation, 
the if/while/for blocks, and the break/throw/return instructions. 
I'll be the first to admit it's kind of minor though.

- It's an obvious monkey patch, and it will clearly have to be 
replaced at some point. It only addresses cases where a reference 
might be escaped through a single return value; it doesn't 
address escaping through 'out' parameters, or through a returned 
tuple.

- It fails to enable useful features like the swap function, or 
storing a scoped value in a container (well, outside of  trusted 
code, but that's beside the point).

- Because it isn't an integral part of the type system, but more 
of an external addition, it has a ton of special cases and little 
gotcha's when you try to do something complex with it. (ref 
parameters can't be scope, can't have pointers on scope values, 
which means you can't pass any kind of scope value by reference, 
you can't have scope types as template parameters, etc)

The two last ones feel like the most important problems to me. If 
all you want to do is variants of the identity function, and 
returning references to attributes, then return ref and return 
scope is everything you need (arguably). If you want to store 
containers of scoped values, swap scope values, and generally 
treat scope as a first-class citizen, then return scope and 
return ref seem like a step in the wrong direction.

The meta problem people seem to have with 'return scope' seems 
more of a social problem. Apparently a lot of people feel like 
you haven't treated their concerns seriously; part of it is that 
as far as I'm aware there hasn't been a proper, open 
brainstorming on how to address lifetime analysis in D.

My reading of the situation, which may be completely off-base, is 
that you took inspiration from Marc Schütz's proposal, and wrote 
something simpler, easier to understand and to code with, and 
following the model you developed when coming up with inout (no 
templates, KISS, don't use up too much language complexity estate 
on an optional feature), then entered a cycle of gradually 
improving it, eventually making DIP-1000.

People who don't like the direction DIP-1000 goes towards are 
upset because they feel way too much effort is going towards 
refining an idea they don't agree with in the first place. To 
speak bluntly, I don't think you've addressed their concerns at 
all, and I hope you do so before 'scope return' is set in stone.


 So, do what numerous people have done numerous times already, 
 to no great effect?


Please don't be hostile. When you have a communication problem, 
being passive-aggressive will only makes it worse.
Jan 28 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/28/2017 6:56 AM, Olivier FAURE wrote:

 For what it's worth, here are my problems with 'return scope':

 - As far as I can tell, it's not properly documented. The github page for
 DIP-1000 is apparently pending a rewrite, and I can't find a formal definition
 of 'return scope' anywhere (the D reference 'Functions' page only mentions
 'return ref', and in passing).


Yes, the documentation could be much better, and will be. Like any battle plan 
doesn't survive the first day of warfare, actually implementing -dip1000 has 
forced several adjustments. I expect more adjustments will be necessary. One of 
the larger difficulties is getting code with -dip1000 and without -dip1000 to 
play together. The bug Dicebot mentioned above is one of those. But this is the 
sort of problem any such scheme will have to deal with.



 - I personally don't like using the return keyword as anything but an
 instruction; when I'm reading code, I can have a good feeling of the code's
flow
 by just looking at the indentation, the if/while/for blocks, and the
 break/throw/return instructions. I'll be the first to admit it's kind of minor
 though.


There's got to be some added syntax somewhere. I'd love to do it as pure 
compiler magic. Amazingly, if the code is all templates, that seems to work
(the 
compiler can infer 'return' and 'scope' as necessary there).



 - It's an obvious monkey patch,


All new features of D have to be worked in to existing features with minimal 
disruption. We're stuck with that reality.



 and it will clearly have to be replaced at some point.
 It only addresses cases where a reference might be escaped through a
 single return value; it doesn't address escaping through 'out' parameters,


Yes it does (the general case is storing a value into any data structure
pointed 
to by an argument).



 or through a returned tuple.


Yes it does (it's as if the tuple elements were fields of a struct).

In general, the idea is to understand what happens with pointers and values. 
Then, to understand how X works, reduce X to its constituent pointers and 
values, and that's how X must work.

It's like in electronics you'll get nowhere trying to understand how an 
amplifier works without thoroughly understand how voltage, current, and 
resistance works. Understanding the amplifier is built up from that.



 - It fails to enable useful features like the swap function, or storing a
scoped
 value in a container (well, outside of  trusted code, but that's beside the
point).


There will be a need for  system code for some things, that is correct. That's 
also true of Rust, where cyclic data structures have to be marked as unsafe,
and 
functions cannot access mutable global data.

Storing a non-trivial data structure in a container is done by hiding the 
pointers in it with 'private' and providing access via the appropriate member 
functions. Safely managing memory is done with ref counted objects or GC memory.

'scope return' and 'ref return' allow ref counting containers to return 
temporary references to their internal data.



 - Because it isn't an integral part of the type system, but more of an external
 addition, it has a ton of special cases and little gotcha's when you try to do
 something complex with it. (ref parameters can't be scope, can't have pointers
 on scope values, which means you can't pass any kind of scope value by
 reference, you can't have scope types as template parameters, etc)


D is a complex language. There are LOTs of ways pointers can be handed around. 
Maybe if we throw D away and start over there would be fewer special cases, but 
we have to work it into the existing semantics.

Yes, you cannot express things in D like a pointer to a scope pointer. Time
will 
tell, but in real code I've seen very little need for such things - little 
enough that it can be handled with  system code.



 The two last ones feel like the most important problems to me. If all you want
 to do is variants of the identity function, and returning references to
 attributes, then return ref and return scope is everything you need (arguably).
 If you want to store containers of scoped values, swap scope values, and
 generally treat scope as a first-class citizen, then return scope and return
ref
 seem like a step in the wrong direction.


Nobody has come up with a better plan. A Rust-like system would require users
to 
not just add annotations, but redesign all their code and data structures. It's 
out of the question.



 The meta problem people seem to have with 'return scope' seems more of a social
 problem. Apparently a lot of people feel like you haven't treated their
concerns
 seriously; part of it is that as far as I'm aware there hasn't been a proper,
 open brainstorming on how to address lifetime analysis in D.


There has been off and on for about 10 years. Little has come of it.

Then came -dip25, which addressed the return ref problem. It worked
surprisingly 
well. There was some severe criticism of it last year as being unusable, but 
those turned out to be implementation bugs that were not difficult to resolve.

'return scope' is little more than extending 'return ref' to deal with values.



 My reading of the situation, which may be completely off-base, is that you took
 inspiration from Marc Schütz's proposal, and wrote something simpler, easier
to
 understand and to code with, and following the model you developed when coming
 up with inout (no templates, KISS, don't use up too much language complexity
 estate on an optional feature), then entered a cycle of gradually improving it,
 eventually making DIP-1000.


A reasonable summary.



 People who don't like the direction DIP-1000 goes towards are upset because
they
 feel way too much effort is going towards refining an idea they don't agree
with
 in the first place. To speak bluntly, I don't think you've addressed their
 concerns at all, and I hope you do so before 'scope return' is set in stone.


It's fair if you don't agree with my rationale, but that isn't the same as not 
addressing them at all. I believe I have addressed the issues you brought up 
here. If you'd like further clarification, please ask.



 So, do what numerous people have done numerous times already, to no great
effect?


 Please don't be hostile. When you have a communication problem, being
 passive-aggressive will only makes it worse.


I didn't write that.
Jan 28 2017
parent reply Olivier FAURE <olivier.faure epitech.eu> writes:
On Saturday, 28 January 2017 at 22:31:23 UTC, Walter Bright wrote:

 It only addresses cases where a reference might be escaped 
 through a
 single return value; it doesn't address escaping through 'out' 
 parameters,


 Yes it does (the general case is storing a value into any data 
 structure pointed to by an argument).


I don't understand. Let's say I have an arbitrary class 
'Container', and I want a function that stores a pointer to an 
int in this container, in a way that lets the function's caller 
know that the int* given to it will last only as long as the 
container, and I want to do it without return values. The 
prototype would be akin to

     void store(ref <scope-info> Container cont, <scope-info> int* 
ptr);

And the code it would be used in would look like:

     {
         scope Container c;
         scope int*      ptr = ...;

         store(c, ptr);
     }

What would the syntax be?


 or through a returned tuple.


 Yes it does (it's as if the tuple elements were fields of a 
 struct).


I meant a little more specific. You have no way to do this

Pair!(int*, float*)   makePair(<scope of return.first> int*,
                                <scope of return.second> float*);

You can declare them both a scope return, but then their scope is 
"merged" into the return value, which may be undesirable if you 
want to treat them differently. Although it's not that important, 
because this particular case would rarely appear in actual 
practical code, unlike swap and out parameters.


 There will be a need for  system code for some things, that is 
 correct. That's also true of Rust, where cyclic data structures 
 have to be marked as unsafe, and functions cannot access 
 mutable global data.


Yeah, but cyclic data structures and complex types are one thing. 
I'm just talking about having a (scope int*)[] type, and a swap 
function. Those should be covered in the scope system, and 
shouldn't need GC or RC.


 Nobody has come up with a better plan. A Rust-like system would 
 require users to not just add annotations, but redesign all 
 their code and data structures. It's out of the question.



 There has been off and on for about 10 years. Little has come 
 of it.

 Then came -dip25, which addressed the return ref problem. It 
 worked surprisingly well. There was some severe criticism of it 
 last year as being unusable, but those turned out to be 
 implementation bugs that were not difficult to resolve.


Well, I liked Schultz's original proposal. It seemed easier to 
theorize formally, and didn't need major redesign the way Rust's 
templates do.

And having read the thread it was proposed in... I didn't see any 
brainstorming? It seems to me that dip25 replaced Schult's 
proposal without transition, or without debate about the merits 
and trade-offs of either proposition, or any rationale explaining 
why Schultz's proposition was abandoned.


 It's fair if you don't agree with my rationale, but that isn't 
 the same as not addressing them at all. I believe I have 
 addressed the issues you brought up here. If you'd like further 
 clarification, please ask.


I'll probably have more to say on that later, but I think THIS is 
the major point of contention. I don't feel like you've addressed 
my concerns, because I'm pretty sure you haven't understood my 
concerns. You interpreted my remarks as obstacles to be overcome, 
not as information I was trying to communicate to you.

I feel like your opinion is that the reason I'm arguing against 
dip1000 is that I don't understand it or its context well enough. 
I feel you have the same opinion of others people who argue 
against the dip. This is what I meant by "not being taken 
seriously".


 I didn't write that.


Sorry, I was replying another poster above in the thread. I'm not 
used to mailing list forums.
Jan 28 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/28/2017 3:56 PM, Olivier FAURE wrote:

 Let's say I have an arbitrary class 'Container', and I want
 a function that stores a pointer to an int in this container, in a way that
lets
 the function's caller know that the int* given to it will last only as long as
 the container, and I want to do it without return values. The prototype would
be
 akin to

     void store(ref <scope-info> Container cont, <scope-info> int* ptr);

 And the code it would be used in would look like:

     {
         scope Container c;
         scope int*      ptr = ...;

         store(c, ptr);
     }

 What would the syntax be?



     c.ptr = ptr;

You can also do:

     ref Container store(ref return scope c, return scope int* ptr);



 You can declare them both a scope return, but then their scope is "merged" into
 the return value, which may be undesirable if you want to treat them
 differently. Although it's not that important, because this particular case
 would rarely appear in actual practical code, unlike swap and out parameters.


Yes, the result is the "merged" scope. This issue is a known (discussed 
previously on the n.g.) limitation. Is it a significant one? I doubt it, as I 
have a hard time contriving a realistic example. Time will tell, though.



 And having read the thread it was proposed in... I didn't see any
brainstorming?
 It seems to me that dip25 replaced Schult's proposal without transition, or
 without debate about the merits and trade-offs of either proposition, or any
 rationale explaining why Schultz's proposition was abandoned.


The rationale is I was looking for a much simpler scheme. Even -dip25 is a very 
simple scheme, and I have a hard time convincing people to use it. What chance 
does a complex annotation scheme have?



 I'll probably have more to say on that later, but I think THIS is the major
 point of contention. I don't feel like you've addressed my concerns, because
I'm
 pretty sure you haven't understood my concerns. You interpreted my remarks as
 obstacles to be overcome, not as information I was trying to communicate to
you.


Aren't problems obstacles to be overcome? I don't really understand your point. 
You ask me to clarify, I try to clarify. You ask how can this be done, I try to 
answer. You say you don't like the syntax, I agree and say I can't find
anything 
better. You say there's a limitation, I agree and say based on my experience 
with it so far it is not a killer limitation.

Please keep in mind we do not have a blank slate. There are serious constraints:

1. dip1000 and non-dip1000 has to coexist
2. cannot ask people to rethink and redesign algorithms and data structures
3. new syntax has to be minimal
4. breaking existing code is unacceptable
5. creating a bondage-and-discipline lifetime tracking annotation system will 
not be acceptable to most users
6. using it needs to be opt-in
7. once one tries to implement something, it gets a lot harder than just
writing 
a spec. Trying to shepherd it through the test suite, Phobos, and existing 
projects is not at all straightforward.

Any system has to deal with those things.

Remember the 'const' system introduced in D2 was nearly universally disliked
for 
years. Over time it has proven its value.

The reason -dip1000 is behind a switch is so it can be developed without 
disruption. Dicebot's bug report in this thread is a crack in that, but I'm 
working on closing it.
Jan 28 2017
parent Olivier FAURE <olivier.faure epitech.eu> writes:
Continuing on a new thread because this is getting kinda 
off-topic.

http://forum.dlang.org/post/jhtvuvhxsayjatsdbhxo forum.dlang.org
Jan 29 2017