On 2014-12-20 23:27:18 +, aldanor said:
- static foreach (declaration foreach)
- fixing __traits templates (eg getProtection vein extremely flaky,
allMembers not working etc) -- seeing as ctfe is one of flagship
features of D, it would make sense to actually make it work flawlessly.
On Thursday, 25 December 2014 at 09:46:19 UTC, Martin Nowak wrote:
On Saturday, 20 December 2014 at 19:22:05 UTC, safety0ff wrote:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak
wrote:
Just wondering what the general sentiment is.
Multiple alias this (DIP66 / #6083.)
It's
On Thursday, 25 December 2014 at 10:06:35 UTC, Martin Nowak wrote:
On Sunday, 21 December 2014 at 12:48:42 UTC, Dicebot wrote:
On Sunday, 21 December 2014 at 12:26:04 UTC, Jacob Carlborg
wrote:
On 2014-12-21 10:46, Dicebot wrote:
Stuff that immediately comes to my mind:
- some way to define
On 2014-12-25 10:11, Martin Nowak wrote:
That's not really a language thing, but indeed important.
Add OS X to that.
--
/Jacob Carlborg
On 2014-12-25 10:29, Martin Nowak wrote:
On Monday, 22 December 2014 at 11:55:36 UTC, Kagamin wrote:
- delegates is another type system hole, if it's not going to be
fixed, then it should be documented
We did fix a few things there, are the rest filed in Bugzilla?
- members of Object
???
On Saturday, 20 December 2014 at 18:42:52 UTC, Vic wrote:
- find all features that are not being maintained or are just
top heavy and deprecate.
- find features that should or could be downstream, and
deprecate.
Any particular suggestions?
On Saturday, 20 December 2014 at 19:51:18 UTC, Benjamin Thaut
wrote:
Am 20.12.2014 18:39, schrieb Martin Nowak:
Shared library support on Windows ;-)
That's not really a language thing, but indeed important.
On Wednesday, 24 December 2014 at 10:35:46 UTC, Paolo Invernizzi
wrote:
On Wednesday, 24 December 2014 at 02:38:02 UTC, Andrei
Alexandrescu wrote:
On 12/20/14 9:39 AM, Martin Nowak wrote:
Shared semantics and improving multithreading also come to
mind. -- Andrei
O God! +1000 ;-P
True, a
On Monday, 22 December 2014 at 11:55:36 UTC, Kagamin wrote:
- delegates is another type system hole, if it's not going to
be fixed, then it should be documented
We did fix a few things there, are the rest filed in Bugzilla?
- members of Object
???
- evaluate contracts at the caller side
On Saturday, 20 December 2014 at 19:22:05 UTC, safety0ff wrote:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak
wrote:
Just wondering what the general sentiment is.
Multiple alias this (DIP66 / #6083.)
It's already in :), at least the DIP just got approved.
Would it really have
On Monday, 22 December 2014 at 11:06:13 UTC, Francesco Cattoglio
wrote:
On Saturday, 20 December 2014 at 20:13:31 UTC, weaselcat wrote:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak
wrote:
Unique! and RefCounted! in a usable state.
+1
No RefCounted classes and non-reentrant GC
On Monday, 22 December 2014 at 09:05:03 UTC, Peter Alexander
wrote:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak
wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection
On Tuesday, 23 December 2014 at 17:34:29 UTC, Dmitry Olshansky
wrote:
- final decision on @property
That one is easy, there is already a semi-offical decision.
http://wiki.dlang.org/DIP23
On Saturday, 20 December 2014 at 20:14:21 UTC, Ola Fosheim
Grøstad wrote:
1. A well thought out ownership system to replace GC with
compiler protocols/mechanisms that makes good static analysis
possible and pointers alias free. It should be designed before
scope is added and a GC-free runtime
On Thursday, 25 December 2014 at 10:39:13 UTC, Martin Nowak wrote:
You might want to respond to
http://forum.dlang.org/post/m5p99m$luk$1...@digitalmars.com or
open a new thread that mentions DIP69 in it's title.
I have responded in the thread. I think ownership has to be
worked out first...
Ola Fosheim Grøstad wrote in message
news:cfqevmhbwagvbqvgd...@forum.dlang.org...
No. Make value parameters immutable, period. No mutable version as an
option. This does not expose anything to the caller.
The same reasoning applies to making all value parameters mutable.
On Wednesday, 24 December 2014 at 08:22:46 UTC, Daniel Murphy
wrote:
The same reasoning applies to making all value parameters
mutable.
Yes, but my point was that making all value parameters mutable is
at odds with correctness when you later edit it since you no
longer know whether it has
On Wednesday, 24 December 2014 at 08:39:26 UTC, Ola Fosheim
Grøstad wrote:
int myfunc(int n){
...lotsofstuff...
x = mayormaynotchange(n);
...lotsofstuff...
return n0 ? x : 0; // modified from return x
}
If you require another variable for a sanitized version of `n`,
you get
On Wednesday, 24 December 2014 at 09:02:56 UTC, Kagamin wrote:
On Wednesday, 24 December 2014 at 08:39:26 UTC, Ola Fosheim
Grøstad wrote:
int myfunc(int n){
...lotsofstuff...
x = mayormaynotchange(n);
...lotsofstuff...
return n0 ? x : 0; // modified from return x
}
If you require
On Wednesday, 24 December 2014 at 09:02:56 UTC, Kagamin wrote:
If you require another variable for a sanitized version of `n`,
you get confused, when to use `n` and when to use `x`, they are
Btw, this is case where preventing shadowing becomes an issue, as
you could have solved this easily
On Wednesday, 24 December 2014 at 09:18:43 UTC, Ola Fosheim
Grøstad wrote:
Not really, because you should strive to keep mutable state
local.
Even if it's local, there are still many similar values to see:
return n0 ? x : 0;
Validation does not belong to the implementation, so the right
way
Ola Fosheim Grøstad wrote in message
news:ggcloheiypsxdssfv...@forum.dlang.org...
Yes, but my point was that making all value parameters mutable is at odds
with correctness when you later edit it since you no longer know whether
it has been modified or not.
Modifying parameters usually
On Wednesday, 24 December 2014 at 02:38:02 UTC, Andrei
Alexandrescu wrote:
On 12/20/14 9:39 AM, Martin Nowak wrote:
Shared semantics and improving multithreading also come to
mind. -- Andrei
O God! +1000 ;-P
---
PAOLO
On Wednesday, 24 December 2014 at 10:32:33 UTC, Daniel Murphy
wrote:
I see this as more of an argument for avoiding long functions.
Marking every possible parameter as const/immutable has a cost,
and I don't think the number of bugs it prevents justifies it.
If it was the default the cost
On Wednesday, 24 December 2014 at 09:46:11 UTC, Kagamin wrote:
On Wednesday, 24 December 2014 at 09:18:43 UTC, Ola Fosheim
Grøstad wrote:
Validation does not belong to the implementation, so the
right way is to put it in a wrapper before you call the
function that does the actual work.
On Wednesday, 24 December 2014 at 11:24:26 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 24 December 2014 at 10:32:33 UTC, Daniel Murphy
wrote:
I want immutable by default, everywhere... Yes.
sanity by default should be the mantra. well, read safety
instead of sanity...
I like the
On Wed, 24 Dec 2014 09:32:05 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Wednesday, 24 December 2014 at 09:02:56 UTC, Kagamin wrote:
If you require another variable for a sanitized version of `n`,
you get confused, when to use `n` and when to use `x`, they are
Btw, this
On Wednesday, 24 December 2014 at 13:10:58 UTC, eles wrote:
C++ is important. Go expected C++ programmers to come, they
received only python co. programmers. People form the C++
world need something better. But they won't trade C++ for
anything less than C++, even if the niche where D would
On Wednesday, 24 December 2014 at 16:10:05 UTC, Ola Fosheim
Grøstad wrote:
And we are not talking yesterdays C++, but next gen x86 C++.
That means 4000 intrinsics, auto-vectorization and possibly
whole program optimization...
Do you propose any changes to the language syntax for
On Wednesday, 24 December 2014 at 17:46:39 UTC, Matthias Bentrup
wrote:
Do you propose any changes to the language syntax for
auto-vectorization and whole program optimization ?
You mean semantics.
As far as I
can see, those are compiler features, they are not related to
the language
On Wednesday, 24 December 2014 at 19:59:31 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 24 December 2014 at 17:46:39 UTC, Matthias
Bentrup wrote:
Do you propose any changes to the language syntax for
auto-vectorization and whole program optimization ?
You mean semantics.
As far as I
can
On Wednesday, 24 December 2014 at 21:01:11 UTC, Paulo Pinto wrote:
Languages like Chapel and X10 are already better candidates in
the HPC community, unless D inherits the same features.
SIMD is important for all applications that want speed, not only
HPC. Being compatible with C is important,
On Tuesday, 23 December 2014 at 01:42:49 UTC, ketmar via
Digitalmars-d wrote:
i really really hate immutable integer args, for example, and
can't
see any sense in doing it. that's why i wondered.
It might be a bit annoying for short functions, but in principle
the function signature should
On Tue, 23 Dec 2014 08:26:15 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Tuesday, 23 December 2014 at 01:42:49 UTC, ketmar via
Digitalmars-d wrote:
i really really hate immutable integer args, for example, and
can't
see any sense in doing it. that's why i wondered.
On Tuesday, 23 December 2014 at 08:43:06 UTC, ketmar via
Digitalmars-d wrote:
that's why we have `in` keyword, which clearly indicates that
argument
is in only. making `in` default is breaking of my lovely
principle of
least astonishment.
in is const scope... But signatures in D are too
I think in, out, inout and scope should go. Make all
parameters that are by-value immutable by default.
I agree with this. In more that could to be interesting if
compiler could translate in to something like const scope
ref when it is an array or heavy object. to save memory
allocation and
On Tuesday, 23 December 2014 at 09:29:20 UTC, Ola Fosheim Grøstad
wrote:
parameters that are ref scope restricted and alias free by
default. Add tuples. Add ways to express that parameters are
Actually, alias free by default might be a bit too much, maybe
just add restricted and a mechanism
20-Dec-2014 20:39, Martin Nowak пишет:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313, 314)
- finishing non-GC memory management
- final decision
On 12/20/14 9:39 AM, Martin Nowak wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313, 314)
- finishing non-GC memory management
Great idea to
On 12/20/14 10:45 AM, Jonathan Marler wrote:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules
Ola Fosheim Grøstad wrote in message
news:gkhgxlioxkzmxbiaz...@forum.dlang.org...
On Tuesday, 23 December 2014 at 01:42:49 UTC, ketmar via Digitalmars-d
wrote:
i really really hate immutable integer args, for example, and can't
see any sense in doing it. that's why i wondered.
It might be
On Wednesday, 24 December 2014 at 07:44:21 UTC, Daniel Murphy
wrote:
Making value parameters immutable, and therefore making the
fact that they're not modified inside the function visible
externally, _IS_ exposing irrelevant aspects of the
implementation in the interface. The caller doesn't
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313,
314)
- finishing non-GC memory
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313,
314)
- finishing non-GC memory
On Saturday, 20 December 2014 at 20:14:21 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak
wrote:
Just wondering what the general sentiment is.
I think the main problem is what is there already, which
prevents more sensible performance features from
On Saturday, 20 December 2014 at 20:13:31 UTC, weaselcat wrote:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak
wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and
On Monday, 22 December 2014 at 11:03:33 UTC, bioinfornatics wrote:
- use everywhere as possible immutability ( const ref, in,
immutable )
Thanks, I forgot that one. Immutable values by default is indeed
an important improvement. All by-value parameters to functions
should be immutable,
- delegates is another type system hole, if it's not going to be
fixed, then it should be documented
- members of Object
- evaluate contracts at the caller side
- streams
- reference type AA
On Mon, 22 Dec 2014 11:17:39 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 22 December 2014 at 11:03:33 UTC, bioinfornatics wrote:
- use everywhere as possible immutability ( const ref, in,
immutable )
Thanks, I forgot that one. Immutable values by default is
On Monday, 22 December 2014 at 21:52:12 UTC, ketmar via
Digitalmars-d wrote:
Thanks, I forgot that one. Immutable values by default is
indeed an important improvement. All by-value parameters to
functions should be immutable, period.
but why? O_O
Because it is safer in long functions where
On Mon, 22 Dec 2014 23:25:11 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 22 December 2014 at 21:52:12 UTC, ketmar via
Digitalmars-d wrote:
Thanks, I forgot that one. Immutable values by default is
indeed an important improvement. All by-value parameters to
Ola Fosheim Grøstad:
1. A well thought out ownership system to replace GC with
compiler protocols/mechanisms that makes good static analysis
possible and pointers alias free. It should be designed before
scope is added and a GC-free runtime should be available.
2. Redesign features and
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
Nice but not important, unless you mean full tuple redesign (not
realistic)
- working
Dicebot:
- tuple support (DIP32, maybe without pattern matching)
Nice but not important, unless you mean full tuple redesign
(not realistic)
Full tuples (without pattern matching) are quite realistic in
D. Tuples have a simple uncontroversial semantics and they get
used everywhere.
On Sunday, 21 December 2014 at 09:58:42 UTC, bearophile wrote:
Dicebot:
- tuple support (DIP32, maybe without pattern matching)
Nice but not important, unless you mean full tuple redesign
(not realistic)
Full tuples (without pattern matching) are quite realistic in
D. Tuples have a
)
- finishing non-GC memory management
What's missing to make D2 feature complete?
Developers to implement said missing features. :)
On 2014-12-21 10:46, Dicebot wrote:
- better user-defined type support (any built-in type must be possible
to emulate via user aggregate)
Any specifics to achieve this?
--
/Jacob Carlborg
- Tuple support would be nice (more minor for me)
- Proper @nogc support (Exceptions in particular make @nogc
unusable in its current state, I've stopped bothering with it)
- Final - virtual support (fairly important)
- Fixing importing / visibility (ie, 314 and other issues)
Besides the
On Sunday, 21 December 2014 at 12:26:04 UTC, Jacob Carlborg wrote:
On 2014-12-21 10:46, Dicebot wrote:
- better user-defined type support (any built-in type must be
possible
to emulate via user aggregate)
Any specifics to achieve this?
Stuff that immediately comes to my mind:
- some way
On Sunday, 21 December 2014 at 09:34:33 UTC, bearophile wrote:
This sounds more ambitious than the hypothetical D3 language :-)
Feature complete should be ambitious! I am only asking for
something a little bit better than C++ ;-) I am not asking for
fringe features like multiple alias
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313, 314)
- finishing non-GC memory management
As a commercial user (but non contributor) of D, here is my
suggestion:
- remove GC and memory management as default
- find all features that are not being maintained or are just top
heavy and deprecate.
- find features that should or could be downstream, and deprecate.
Vic
-
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313,
314)
- finishing non-GC memory
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
Multiple alias this (DIP66 / #6083.)
Am 20.12.2014 18:39, schrieb Martin Nowak:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313, 314)
- finishing non-GC memory management
Shared library
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313,
314)
- finishing non-GC memory
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313,
314)
- finishing non-GC memory
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
I think the main problem is what is there already, which prevents
more sensible performance features from being added and also is
at odds with ensuring correctness.
By priority:
I forgot:
1.5 Explicit inlining and fixing the import system.
On Saturday, 20 December 2014 at 18:42:52 UTC, Vic wrote:
As a commercial user (but non contributor) of D, here is my
suggestion:
- remove GC and memory management as default
I sure hope not. It would eat a lot of developer time, and then
the anti-GC crowd would switch to complaining about
- static foreach (declaration foreach)
- fixing __traits templates (eg getProtection vein extremely
flaky, allMembers not working etc) -- seeing as ctfe is one of
flagship features of D, it would make sense to actually make it
work flawlessly.
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313,
314)
- finishing non-GC memory
72 matches
Mail list logo
