This is a rather important pull request and the last big milestone for
the 1.0.0 release. I'd like to get the next version out shortly, but
this PR is sitting idle for over a month now and partially blocks
development.
It consists of mostly just documentation additions, deprecations/name
chan
On Monday, April 18, 2016 20:49:45 jmh530 via Digitalmars-d wrote:
> As an aside, the reason for not having function attribute
> inference everywhere is that it doesn't work when function bodies
> are not available. How common is this? I feel like I never write
> functions like this. Why not just m
On Tuesday, April 19, 2016 03:27:46 Marco Leise via Digitalmars-d wrote:
> No case makes the distinction between "function body
> availability" and "API stability" more clear than auto return.
> Even though their source code is copied verbatim into the .di
> files to allow the return of voldemort t
Currently the compiler makes sure, that it can see the entire
nested call chain when performing attribute inference. So it
limits itself to function literals and templates where the
source has to be right there for them to compile.
The remaining functions could roughly be classified as
functions t
On Tuesday, 19 April 2016 at 01:13:01 UTC, deadalnix wrote:
On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
We plan to add a set of numeric packages and this would be
real pain if they would be one-by-one moved from experimental
to stable std. So sci.* should be considered as e
On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
We plan to add a set of numeric packages and this would be real
pain if they would be one-by-one moved from experimental to
stable std. So sci.* should be considered as experimental
during few years.
https://github.com/dlang/ph
Am Mon, 18 Apr 2016 20:49:45 +
schrieb jmh530 :
> As an aside, the reason for not having function attribute
> inference everywhere is that it doesn't work when function bodies
> are not available. How common is this? I feel like I never write
> functions like this. Why not just make the rul
On Monday, 18 April 2016 at 20:24:40 UTC, Jesse Phillips wrote:
On Sunday, 17 April 2016 at 15:23:50 UTC, w0rp wrote:
void main() {
// Print all directories from this one up to and including
/.
getcwd()
.unaryRecurrence!dirName
.until("/", OpenRight.no)
.each!writeln;
}
F
On Monday, 18 April 2016 at 12:02:24 UTC, thedeemon wrote:
On Sunday, 17 April 2016 at 15:23:50 UTC, w0rp wrote:
auto unaryRecurrence(alias func, T)(T initialValue) {
return recurrence!((values, index) =>
func(values[0]))(initialValue);
}
This is kind of neat. My question is, should som
Am Mon, 18 Apr 2016 15:15:26 +
schrieb Atila Neves :
Just remember that makefiles are well integrated with other
systems (i.e. package managers) and there are some
conventions, about what certain environment variables mean.
To name a few:
MAKEOPTS=-j4 (parallel build with N processes)
DC=/op
On Monday, 18 April 2016 at 19:57:42 UTC, cym13 wrote:
@default = @safe @nogc @pure
int foo(int i) { ... } // This function is @safe @nogc @pure
int bar(int i) @pure { ... } // This function is only @pure
Why not just put
@safe @nogc pure:
at the top? I feel like @default would
On Monday, 18 April 2016 at 19:57:42 UTC, cym13 wrote:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
http://wiki.dlang.org/DIP64
Attributes in D have two problems:
1. There are too many of them and declarations are getting too
verbose
2. New attributes use @ and the old ones do
On Sunday, 17 April 2016 at 15:23:50 UTC, w0rp wrote:
void main() {
// Print all directories from this one up to and including
/.
getcwd()
.unaryRecurrence!dirName
.until("/", OpenRight.no)
.each!writeln;
}
FYI, OS independent version:
void main() {
// Print all direc
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
http://wiki.dlang.org/DIP64
Attributes in D have two problems:
1. There are too many of them and declarations are getting too
verbose
2. New attributes use @ and the old ones do not.
I've created a DIP to address these issues.
Two
I know people who discovered at the check-in counter that their passport
had expired. :)
Ali
On Monday, 18 April 2016 at 17:41:56 UTC, Ali Çehreli wrote:
I know people who discovered at the check-in counter that their
passport had expired. :)
Thanks for the reminder. Mine is ok.
On 4/18/16 12:13 PM, Dejan Lekic wrote:
On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
We plan to add a set of numeric packages and this would be real pain
if they would be one-by-one moved from experimental to stable std. So
sci.* should be considered as experimental during fe
On Monday, 18 April 2016 at 16:13:54 UTC, Dejan Lekic wrote:
As I have said many times on both IRC and NG, I would prefer to
have `stdx` instead of ridiculously long (4x)
`std.experimental`. Then you would have a nice package named
`stdx.sci`.
How often are you typing in import statements tha
On Monday, 18 April 2016 at 16:13:54 UTC, Dejan Lekic wrote:
As I have said many times on both IRC and NG, I would prefer to
have `stdx` instead of ridiculously long (4x)
`std.experimental`. Then you would have a nice package named
`stdx.sci`.
Fantastic idea (that I had not heard before).
On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
We plan to add a set of numeric packages and this would be real
pain if they would be one-by-one moved from experimental to
stable std. So sci.* should be considered as experimental
during few years.
https://github.com/dlang/ph
On 4/17/16 6:04 AM, ag0aep6g wrote:
On 17.04.2016 11:44, Ilya Yaroshenko wrote:
This would be a real pain for a user if he supports few compiler
versions.
static if(__VERSION__ < 2072)
{
import std.experimental.sci.ndslice;
}
else
{
import std.sci.ndslice;
}
[...]
Breakage is what
On Monday, 18 April 2016 at 15:15:26 UTC, Atila Neves wrote:
Here's[1] another attempt at converting the Makefile for POSIX
systems to D using reggae[2].
Great work! This transition cannot happen soon enough.
Maintaining the make files is a huge pain and something always
falls through the cra
Here's[1] another attempt at converting the Makefile for POSIX
systems to D using reggae[2]. I first tried my hand at writing a
parser for Makefiles using Pegged and machine translating to D. I
learned a lot about parsing and GNU make in the process and also
that:
1. It was about two orders o
On Monday, April 18, 2016 13:10:59 jmh530 via Digitalmars-d wrote:
> On Monday, 18 April 2016 at 12:11:46 UTC, Jonathan M Davis wrote:
> > Regardless, changing any of the attributes now would break a
> > _lot_ of code, and such a change would have to be worth the
> > pain that it would cause, which
On Monday, 18 April 2016 at 12:11:46 UTC, Jonathan M Davis wrote:
Regardless, changing any of the attributes now would break a
_lot_ of code, and such a change would have to be worth the
pain that it would cause, which is questinonable.
dfix has a DIP64 switch, right?
On Monday, 18 April 2016 at 08:53:31 UTC, Guillaume Piolat wrote:
And shared and @property :)
I still want to see @property fixed rather than removed - the
edge case with returning a delegate is an interesting one to me
(though that's ALL I want it to do, leave everything else alone)
On Monday, April 18, 2016 10:32:39 Satoshi via Digitalmars-d wrote:
> On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
> > http://wiki.dlang.org/DIP64
> >
> > Attributes in D have two problems:
> > 1. There are too many of them and declarations are getting too
> > verbose
> > 2. New att
On Sunday, 17 April 2016 at 15:23:50 UTC, w0rp wrote:
auto unaryRecurrence(alias func, T)(T initialValue) {
return recurrence!((values, index) =>
func(values[0]))(initialValue);
}
This is kind of neat. My question is, should something like
this function be included in std.range? Either
On Thursday, 21 May 2015 at 13:40:22 UTC, Rikki Cattermole wrote:
On 22/05/2015 1:30 a.m., Baz wrote:
Still the best git GUI but it has some obvious problems and
bugs.
IMO making a good UI for VC is hard. As you said even
SourceTree isn't perfect.
If only somebody could make a better cross
On Monday, 18 April 2016 at 10:32:39 UTC, Satoshi wrote:
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
http://wiki.dlang.org/DIP64
Attributes in D have two problems:
1. There are too many of them and declarations are getting too
verbose
2. New attributes use @ and the old ones
On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
http://wiki.dlang.org/DIP64
Attributes in D have two problems:
1. There are too many of them and declarations are getting too
verbose
2. New attributes use @ and the old ones do not.
I've created a DIP to address these issues.
Lan
On Friday, 15 April 2016 at 21:01:44 UTC, Andrei Alexandrescu
wrote:
Jesus. C++ has const without inout. We used to have const
without inout - and we probably should again. -- Andrei
What about immutability? E.g. Java gets away with immutable in a
library and it just werks.
On 18.04.2016 00:08, Bauss wrote:
On Sunday, 17 April 2016 at 21:59:38 UTC, Timon Gehr wrote:
On 17.04.2016 23:49, Bauss wrote:
On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
mixin(generate());
pragma(msg,generate());
That's not a solution to the problem, because you will be pr
On Saturday, 16 April 2016 at 11:49:21 UTC, Nick Treleaven wrote:
On 16/04/2016 12:40, Marc Schütz wrote:
What are the plans for DIP25's `return` attribute? Because
with it, the
compiler has enough information to know that the return value
aliases `s`:
const(T)[] replaceSlice(T)(const(T)[] s
On Monday, 18 April 2016 at 08:52:19 UTC, Guillaume Piolat wrote:
Personnally I wish synchronized, comma operator, and actively
harmful things would go. nothrow provides little value, but no
negative value.
And shared and @property :)
But I guess this isn't Christmas already.
On Sunday, 17 April 2016 at 23:03:26 UTC, Adam D. Ruppe wrote:
On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
On 17.04.2016 18:44, Nick Treleaven wrote:
I think @property is OK.
No, it isn't:
Seriously, @property is one of the biggest SNAFUs of the
language.
I think I'll wr
36 matches
Mail list logo
