On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
All review-related feedback on and discussion of the DIP should
occur in this thread. Due to DConf taking place during
https://github.com/dlang/DIPs/pull/63
On Thursday, 11 May 2017 at 17:35:31 UTC, Nick Sabalausky
(Abscissa) wrote:
It is already addressed in the DIP. FQNs only help if they are
used and
current idiomatic D code tends to rely on unqualified
imports/names.
I didn't see that. Certainly not in the "Existing solutions"
section. It
On 5/11/17 1:21 PM, Nick Sabalausky (Abscissa) wrote:
On 05/11/2017 07:19 AM, Steven Schveighoffer wrote:
On 5/11/17 12:11 AM, Nick Sabalausky (Abscissa) wrote:
This is a pointless limitation. What is the benefit of requiring the
author to *not* provide an implementation until the transition
On 05/11/2017 06:10 AM, Dicebot wrote:
On Thursday, 11 May 2017 at 03:46:55 UTC, Nick Sabalausky (Abscissa) wrote:
1. Why are FQNs alone (assume they still worked like they're supposed
to) not good enough? Needs to be addressed in DIP. Currently isn't.
It is already addressed in the DIP. FQNs
On 05/11/2017 07:19 AM, Steven Schveighoffer wrote:
On 5/11/17 12:11 AM, Nick Sabalausky (Abscissa) wrote:
This is a pointless limitation. What is the benefit of requiring the
author to *not* provide an implementation until the transition period is
over? It runs counter to normal workflow.
On 5/11/17 12:11 AM, Nick Sabalausky (Abscissa) wrote:
On 04/25/2017 08:33 AM, Steven Schveighoffer wrote:
In the general case, one year is too long. A couple compiler releases
should be sufficient.
* When the @future attribute is added, would one add it on a dummy
symbol or would one
On Thursday, 11 May 2017 at 03:46:55 UTC, Nick Sabalausky
(Abscissa) wrote:
1. Why are FQNs alone (assume they still worked like they're
supposed to) not good enough? Needs to be addressed in DIP.
Currently isn't.
It is already addressed in the DIP. FQNs only help if they are
used and
On Thursday, 11 May 2017 at 00:04:52 UTC, Steven Schveighoffer
wrote:
I prefer the first one. The reason is simply because it doesn't
require any new grammar. The override requirement is already a
protection against changing base class. In this case, we have
two possible outcomes:
1. The
On 04/25/2017 08:33 AM, Steven Schveighoffer wrote:
In the general case, one year is too long. A couple compiler releases
should be sufficient.
* When the @future attribute is added, would one add it on a dummy
symbol or would one provide the implementation as well?
dummy symbol. Think of
On 05/10/2017 11:04 PM, Nick Sabalausky (Abscissa) wrote:
On 05/10/2017 09:51 PM, Nick Sabalausky (Abscissa) wrote:
This is what FQNs are for. At least, it was before FQNs were broken,
first by an incomplete "package.d" system and second by a goofy
half-baked change to import rules.
FQNs need
On 05/10/2017 09:51 PM, Nick Sabalausky (Abscissa) wrote:
This is what FQNs are for. At least, it was before FQNs were broken,
first by an incomplete "package.d" system and second by a goofy
half-baked change to import rules.
FQNs need fixed. This DIP is just a questionable workaround for our
This is what FQNs are for. At least, it was before FQNs were broken,
first by an incomplete "package.d" system and second by a goofy
half-baked change to import rules.
FQNs need fixed. This DIP is just a questionable workaround for our
borked FQNs that that smacks of C++-style "no breakage at
On 5/10/17 11:15 AM, Dicebot wrote:
On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer wrote:
Actually, that brings up a problem with this, what is the mechanism to
say "maybe override"? Let's say you have:
// in imported library
class Base
{
void foo() @future;
}
// in user
On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer
wrote:
Actually, that brings up a problem with this, what is the
mechanism to say "maybe override"? Let's say you have:
// in imported library
class Base
{
void foo() @future;
}
// in user library
class Derived : Base
{
On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer
wrote:
Really, what you are doing is reserving the overload spot. In
cases where the overload would have selected your local
function, then you should get no warning (as the additional
symbol won't conflict). In cases where your
On Monday, 24 April 2017 at 15:58:12 UTC, rikki cattermole wrote:
On the flip side, it would be great for development, feature
not yet done but planned? Annotate it. Even before a release
ever happens.
This is not the intended usage of this DIP. The intention here is
to only mark symbols
On 4/28/17 4:31 AM, Olivier FAURE wrote:
On Wednesday, 26 April 2017 at 11:26:19 UTC, Steven Schveighoffer wrote:
I'm wondering if you actually wrote this? It seems to be quoted.
That was a quote from the DIP. (guess I should have used a colon)
Ah, OK. Sorry for the confusion, I wasn't sure
On Wednesday, 26 April 2017 at 11:26:19 UTC, Steven Schveighoffer
wrote:
I'm wondering if you actually wrote this? It seems to be quoted.
That was a quote from the DIP. (guess I should have used a colon)
On 4/26/17 4:32 AM, Olivier FAURE wrote:
On Tuesday, 25 April 2017 at 18:32:09 UTC, Steven Schveighoffer wrote:
I missed this part. Now that I read that, I think we aren't going to
gain much by having this language feature internal to the compiler.
The way I understood it, the feature will
On Tuesday, 25 April 2017 at 18:32:09 UTC, Steven Schveighoffer
wrote:
I missed this part. Now that I read that, I think we aren't
going to gain much by having this language feature internal to
the compiler.
The way I understood it, the feature will only stay internal to
the compiler until
On 4/25/17 12:24 PM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Apr 24, 2017 at 04:58:12PM +0100, rikki cattermole via Digitalmars-d
wrote:
On 24/04/2017 4:03 PM, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
On Mon, Apr 24, 2017 at 04:58:12PM +0100, rikki cattermole via Digitalmars-d
wrote:
> On 24/04/2017 4:03 PM, Mike Parker wrote:
> > DIP 1007 is titled "'future symbol' Compiler Concept".
> >
> > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
[...]
> This DIP concerns me, for any other
On 4/24/17 11:03 AM, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
All review-related feedback on and discussion of the DIP should occur in
this thread. Due to DConf taking place during the review period, the
On 4/25/17 7:29 AM, Jacob Carlborg wrote:
On 2017-04-24 17:03, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
All review-related feedback on and discussion of the DIP should occur in
this thread. Due to DConf
On 25/04/2017 12:29 PM, Jacob Carlborg wrote:
On 2017-04-24 17:03, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
All review-related feedback on and discussion of the DIP should occur in
this thread. Due to
On 2017-04-24 17:03, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
All review-related feedback on and discussion of the DIP should occur in
this thread. Due to DConf taking place during the review period, the
On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
+1
I like the idea of beeing warned about new symbols in libraries,
so that I can change my symbols ahead.
On Monday, 24 April 2017 at 22:22:14 UTC, Atila Neves wrote:
In headers. Not in source files, and I don't know why anyone
would want to keep typing `std::` all the time.
C++ is increasingly becoming dependent on templates so header
files are expanding at the cost of ".cpp source files". If
On Monday, 24 April 2017 at 15:22:15 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
«In all the mentioned languages but D, a common convention is
to only use unqualified access for symbols in
On 24/04/2017 4:03 PM, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
All review-related feedback on and discussion of the DIP should occur in
this thread. Due to DConf taking place during the review period,
On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
«In all the mentioned languages but D, a common convention is to
only use unqualified access for symbols in the standard library.»
Not quite right for C++. The common
On Monday, 24 April 2017 at 15:14:44 UTC, Mike Parker wrote:
DIP 1006 is titled "'future symbol' Compiler Concept". This
Apologies, this is DIP 1007, not 1006.
DIP 1006 is titled "'future symbol' Compiler Concept". This
announcement kicks off the first round of preliminary reviews.
The review thread can be found in the General forum at:
http://forum.dlang.org/post/hjdstwzhcbrektlij...@forum.dlang.org
Please also remember that the first preliminary
DIP 1007 is titled "'future symbol' Compiler Concept".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
All review-related feedback on and discussion of the DIP should
occur in this thread. Due to DConf taking place during the review
period, the period will be extended by a week. The
35 matches
Mail list logo
