Maybe someone should remove this from the Changelog?
http://dlang.org/changelog.html#partial-type
On Mon, 02 Feb 2015 19:13:13 +, Ola Fosheim Grøstad wrote:
sure, to fully exploit that (and other things) it's better to drop that
oldish object files concept and use something like delphi's .dcu.
I am not familiar with that format, but using a high level intermediate
representation
On 2/1/15 9:26 AM, Andrei Alexandrescu wrote:
I agree indecision is bad. -- Andrei
Whereas I'm still on the fence...
On Monday, 2 February 2015 at 20:51:02 UTC, ketmar wrote:
i think that this is the area that can be left to
platform-specific
part of the specs. maybe even omited completely, as it's highly
backend/
arch dependent. if someone want to squeeze every cycle
possible, he knows
that his code will
On Monday, 2 February 2015 at 10:28:37 UTC, ketmar wrote:
but to work on D3 people should be interested in D. and it
seems that people who are interested in D and are ready to
work on D development
already have some codebases. i don't believe that they will
welcome yet
another codebase
On Mon, 02 Feb 2015 09:07:37 +, Ola Fosheim Grøstad wrote:
On Monday, 2 February 2015 at 05:44:46 UTC, ketmar wrote:
i agree with you, but it's really too late to redesign. :-( it's not
about code breaking, people just will not join D3 (or something)
developement at this stage.
I
On Mon, 02 Feb 2015 14:11:20 +, Ola Fosheim Grøstad wrote:
On Monday, 2 February 2015 at 10:28:37 UTC, ketmar wrote:
but to work on D3 people should be interested in D. and it seems that
people who are interested in D and are ready to work on D development
already have some codebases. i
On Monday, 2 February 2015 at 15:24:15 UTC, ketmar wrote:
and lambdas, which i'm using in gcc too. and i don't really
need that
@safe and pure things -- hey, if compiler is able to check
that, it's
able to infer that, so do it and just get out of my way! ah,
and nothrow
too. let me force that
On Monday, 2 February 2015 at 05:44:46 UTC, ketmar wrote:
i agree with you, but it's really too late to redesign. :-(
it's not about code breaking, people just will not join D3 (or
something) developement at this stage.
I don't agree. D does not have a significant set of libraries
that
Whatever, anyway.
Translation of that being:
Boring pedestrian issues like simple string logging are
bikeshedded for YEARS, yet PhD-level esoteric stuff makes it into
phobos with relative ease.
https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md
cautios and determination,
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
Whatever, anyway.
Translation of that being:
Boring pedestrian issues like simple string logging are
bikeshedded for YEARS, yet PhD-level esoteric stuff makes it
into phobos with relative ease.
On Sunday, 1 February 2015 at 10:00:38 UTC, uri wrote:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
W.r.t this feature, I was personally looking forward to it ...
guess I'll stick with the Octave/R/Python troika for rapid
protoyping numerical analysis code.
Unfortunately for
On Saturday, 31 January 2015 at 07:57:19 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 31 January 2015 at 07:00:05 UTC, eles wrote:
Can you use it in function parameters?
Will it be made superfluous if you have tuple literals?
*these* are very different grounds on which to discuss, accept
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
Boring pedestrian issues like simple string logging are
bikeshedded for YEARS, yet PhD-level esoteric stuff makes it
into phobos with relative ease.
At least for me, this was a valuable English lesson. I had never
quite grasp the
On Friday, 30 January 2015 at 22:34:25 UTC, Walter Bright wrote:
Unless a new language feature is a compelling win
You seem to never measure win in terms of user experience,
but in abstract technicality.
Blackberry lost in front of Apple exactly for the same reason.
On Saturday, 31 January 2015 at 07:19:47 UTC, Andrei Alexandrescu
wrote:
On 1/30/15 11:00 PM, eles wrote:
On Friday, 30 January 2015 at 18:08:15 UTC, Gary Willoughby
wrote:
On Friday, 30 January 2015 at 14:47:22 UT
How is anything about specifying the length of a constant array
On 2/1/15 1:54 AM, eles wrote:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
Boring pedestrian issues like simple string logging are bikeshedded
for YEARS, yet PhD-level esoteric stuff makes it into phobos with
relative ease.
At least for me, this was a valuable English lesson. I
On Sunday, 1 February 2015 at 15:41:38 UTC, Tobias Pankrath wrote:
On Sunday, 1 February 2015 at 10:00:38 UTC, uri wrote:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
Because static arrays are not convenient enough to use, I'll
have to use another language that does not even
On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu
wrote:
I know it's impossible to please everyone and I'm not sure how
we can convert your frustration into something productive. --
How about designing the language before implementing it? Then one
can discuss the design, rather
On Sunday, 1 February 2015 at 09:20:11 UTC, eles wrote:
but the grounds that I was criticizing were not this ones. were
the grounds of it ma be done otherwise, just look at this nice
bed-of-nails syntax!
Yeah, I agree that the library solution for what should be
builtin makes no sense.
In
On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu
wrote:
On 2/1/15 1:54 AM, eles wrote:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
Well I don't know what to say. I agree with some of your points
but not with most. It's a bummer you are being frustrated, but
I
On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu
wrote:
On 2/1/15 1:54 AM, eles wrote:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
I know it's impossible to please everyone and I'm not sure how
But that everyone is many. Have a look, please, at the comments
On Sun, 01 Feb 2015 15:56:17 +, eles wrote:
Propensity for bike-shedding behind the covers of intellectual
refinement puzzles me.
this is part of be smart! strategy. anyone who is not smart enough
doesn't deserve the right to use D. and being smart means manually do
the work that
On Sunday, 1 February 2015 at 15:41:38 UTC, Tobias Pankrath wrote:
Because static arrays are not convenient enough to use, I'll
have to use another language that does not even provide static
arrays. Makes sense.
Kind of OT, but can we drop this static/dynamic/associative array
thing ?
On 1 February 2015 at 09:46, eles via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Whatever, anyway.
Translation of that being:
Boring pedestrian issues like simple string logging are bikeshedded for
YEARS, yet PhD-level esoteric stuff makes it into phobos with relative
ease.
On 2/1/15 8:24 AM, eles wrote:
On Sunday, 1 February 2015 at 16:09:24 UTC, eles wrote:
On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu wrote:
On 2/1/15 1:54 AM, eles wrote:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
9 years...
And, for what it matters, 9
On Sunday, 1 February 2015 at 16:09:02 UTC, ketmar wrote:
On Sun, 01 Feb 2015 15:56:17 +, eles wrote:
this is part of be smart! strategy. anyone who is not smart
enough
doesn't deserve the right to use D. and being smart means
manually do
the work that compiler can automate.
Well, at
On 2/1/15, deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Sunday, 1 February 2015 at 15:41:38 UTC, Tobias Pankrath wrote:
Because static arrays are not convenient enough to use, I'll
have to use another language that does not even provide static
arrays. Makes sense.
Kind
On 2/1/15 2:00 AM, uri wrote:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
Whatever, anyway.
Translation of that being:
Boring pedestrian issues like simple string logging are bikeshedded
for YEARS, yet PhD-level esoteric stuff makes it into phobos with
relative ease.
On Sunday, 1 February 2015 at 16:09:24 UTC, eles wrote:
On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu
wrote:
On 2/1/15 1:54 AM, eles wrote:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
9 years...
And, for what it matters, 9 years of *indecision*.
It wasn't a
On Sunday, 1 February 2015 at 10:00:38 UTC, uri wrote:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
W.r.t this feature, I was personally looking forward to it ...
guess I'll stick with the Octave/R/Python troika for rapid
protoyping numerical analysis code.
Because static
On Sunday, 1 February 2015 at 15:46:44 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 1 February 2015 at 09:20:11 UTC, eles wrote:
Yeah, I agree that the library solution for what should be
builtin makes no sense.
Yet, there is such a bias for over-appreciating the library
features... an
On Sunday, 1 February 2015 at 16:09:24 UTC, eles wrote:
On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu
wrote:
On 2/1/15 1:54 AM, eles wrote:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
I know it's impossible to please everyone and I'm not sure how
But that
On 2/1/15 1:03 PM, uri wrote:
int[$] a=[1,2,3];
The syntax sugar helps when prototyping ideas, which is why R and Octave
(MATLAB) are so useful.
Do R, Octave, or Matlab have the ability to define arrays on the stack?
-- Andrei
On Sunday, 1 February 2015 at 15:36:04 UTC, Andrei Alexandrescu
wrote:
On 2/1/15 2:00 AM, uri wrote:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:
Whatever, anyway.
Translation of that being:
Boring pedestrian issues like simple string logging are
bikeshedded
for YEARS, yet
On Sunday, 1 February 2015 at 16:09:02 UTC, ketmar wrote:
On Sun, 01 Feb 2015 15:56:17 +, eles wrote:
Propensity for bike-shedding behind the covers of intellectual
refinement puzzles me.
this is part of be smart! strategy. anyone who is not smart
enough
doesn't deserve the right to use
On Sunday, 1 February 2015 at 23:19:53 UTC, Andrei Alexandrescu
wrote:
On 2/1/15 1:03 PM, uri wrote:
int[$] a=[1,2,3];
The syntax sugar helps when prototyping ideas, which is why R
and Octave
(MATLAB) are so useful.
Do R, Octave, or Matlab have the ability to define arrays on
the stack?
On Mon, 02 Feb 2015 00:00:00 +, Ola Fosheim Grøstad wrote:
On Sunday, 1 February 2015 at 16:09:02 UTC, ketmar wrote:
On Sun, 01 Feb 2015 15:56:17 +, eles wrote:
Propensity for bike-shedding behind the covers of intellectual
refinement puzzles me.
this is part of be smart!
On Saturday, 31 January 2015 at 07:00:05 UTC, eles wrote:
Everytime I follow the process managemnt and decision in D, it
looks to me like IndburIII-esque:
What management? You mean the process that follow the structure:
- analysis
- prioritization
- risk reduction
- design
- implementation
-
On Saturday, 31 January 2015 at 07:19:47 UTC, Andrei Alexandrescu
wrote:
On 1/30/15 11:00 PM, eles wrote:
On Friday, 30 January 2015 at 18:08:15 UTC, Gary Willoughby
wrote:
On Friday, 30 January 2015 at 14:47:22 UT
We don't want the situation of C++ where people only use 80%
of it's
On 30/01/2015 16:44, Kenji Hara via Digitalmars-d wrote:
immutable[][$] a2 = [[1,2], [3,4]]; // a static array of mutable
dynamic array of immutable ints
static assert(is(typeof(a2) == immutable(int)[][2]));
...
The type deduction will provide powerful way to type variables.
Yes,
On 30/01/2015 17:01, Kenji Hara via Digitalmars-d wrote:
2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d
digitalmars-d@puremagic.com:
This version of staticArray allows the user to (optionally) specify the
element type.
How the API can replace following declaration with ?
On 30/01/2015 16:44, Kenji Hara via Digitalmars-d wrote:
The new feature, I call it Partial type deduction, is not only for static
array length.
Yes, I think the other improvements are useful, but [$] is not strictly
necessary. Maybe [$] will turn out to be worth having, but I'm not sure
2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d
digitalmars-d@puremagic.com:
This version of staticArray allows the user to (optionally) specify the
element type.
How the API can replace following declaration with ?
auto[$][][$] = [
[[1,2]],
[[3,4], [5,6]],
[[7,8],
On 30/01/2015 14:47, Andrei Alexandrescu wrote:
The recent int[$] feature seems to fail that test. That feature, and in
fact more, can be done trivially with library code:
http://dpaste.dzfl.pl/f49a97e35974.
+1. Also discussed here:
https://issues.dlang.org/show_bug.cgi?id=8008#c8
2015-01-30 23:47 GMT+09:00 Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com:
Please advise.
The new feature, I call it Partial type deduction, is not only for static
array length.
Examples:
void main()
{
const[] a1 = [1,2,3]; // a mutable array of const ints
static
On Fri, 30 Jan 2015 18:08:13 +, Gary Willoughby wrote:
We don't want the situation of C++ where people only use 80% of it's
features and that 80% is different for everyone. I've recently been
writing some Go code and it's become clear to me just how big of a
language D really is.
that is
On 1/30/2015 10:21 AM, Andrei Alexandrescu wrote:
On 1/30/15 9:57 AM, H. S. Teoh via Digitalmars-d wrote:
If it wasn't a good idea, I don't have a problem with reverting it, but
what I'm wondering is, why raise the objection *now* rather than *months*
ago when the PR was sitting in the queue
On 30/01/2015 16:53, Nick Treleaven wrote:
This version of staticArray allows the user to (optionally) specify the
element type.
Actually, I'm having trouble implementing staticArray like that, perhaps
there are compiler issues causing problems. Using this:
T[len] staticArray(T, size_t
On Friday, 30 January 2015 at 14:47:22 UTC, Andrei Alexandrescu
wrote:
So I am think we should consider reverting
https://github.com/D-Programming-Language/dmd/pull/3615 and
adding the appropriate functions to std.array.
Please advise.
+1
Woah, please stop adding syntax and focus on
On Friday, 30 January 2015 at 14:47:22 UTC, Andrei Alexandrescu
wrote:
As discussed in this forum, Kenji has authored
https://github.com/D-Programming-Language/dmd/pull/3615 which
has been recently merged.
By this I am proposing we revert that decision, and quickly -
before 2.067 is released
Unless a new language feature is a compelling win, we should err on the side of
being conservative.
With the array.s library function idea, it seems that the utility of this new
syntax is greatly reduced.
I say no.
On Friday, 30 January 2015 at 20:43:10 UTC, Andrei Alexandrescu
wrote:
I think if you showed someone auto declarations and then
showed them
something like auto[] arr = [...], their likely reaction would
be well
of course that works. Although maybe I'm too familiar with D
at this
point and
On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven wrote:
On 30/01/2015 16:53, Nick Treleaven wrote:
This version of staticArray allows the user to (optionally)
specify the
element type.
Actually, I'm having trouble implementing staticArray like
that, perhaps there are compiler
On 1/30/15 9:57 AM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jan 30, 2015 at 06:47:22AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
As discussed in this forum, Kenji has authored
https://github.com/D-Programming-Language/dmd/pull/3615 which has been
recently merged.
By this I am
On Friday, 30 January 2015 at 14:47:22 UTC, Andrei Alexandrescu
wrote:
Please advise.
Andrei
+1
D's syntax is already big enough, if anything it needs reduced.
On Fri, Jan 30, 2015 at 06:47:22AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
As discussed in this forum, Kenji has authored
https://github.com/D-Programming-Language/dmd/pull/3615 which has been
recently merged.
By this I am proposing we revert that decision, and quickly - before
On Friday, 30 January 2015 at 18:11:43 UTC, weaselcat wrote:
On Friday, 30 January 2015 at 14:47:22 UTC, Andrei Alexandrescu
wrote:
Please advise.
Andrei
+1
D's syntax is already big enough, if anything it needs reduced.
What would you remove?
On 1/30/15 10:40 AM, Foo wrote:
On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven wrote:
On 30/01/2015 16:53, Nick Treleaven wrote:
This version of staticArray allows the user to (optionally) specify the
element type.
Actually, I'm having trouble implementing staticArray like that,
On 1/30/15 9:01 AM, Kenji Hara via Digitalmars-d wrote:
2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com:
This version of staticArray allows the user to (optionally) specify
the element type.
How the API can
On Friday, 30 January 2015 at 19:07:53 UTC, Andrei Alexandrescu
wrote:
On 1/30/15 10:40 AM, Foo wrote:
On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven
wrote:
On 30/01/2015 16:53, Nick Treleaven wrote:
This version of staticArray allows the user to (optionally)
specify the
element
On 1/30/15 12:33 PM, Meta wrote:
I'm somewhat neutral on [$], although I think it is useful. I like the
partial type deduction feature and think we should keep that. It makes a
lot of array declarations more concise, and subjectively, I think it
feels like a natural extension of what D already
If it is only a way to infer static array types I am inclined to
agree that benefit is not big enough. If some more powerful and
generic inference is built on top of it that would be a different
story - but I haven't followed that specific discussion and don't
know if there is anything extra
On Saturday, 31 January 2015 at 05:07:35 UTC, Kapps wrote:
On Friday, 30 January 2015 at 19:07:53 UTC, Andrei Alexandrescu
wrote:
The interesting thing is because of the tight overloading
rules, s will only match statically-sized arrays. So it's
okay to simply expose it as std.array.s
P.S. does it have a DIP? Is it http://wiki.dlang.org/DIP34 ?
On Friday, 30 January 2015 at 19:07:53 UTC, Andrei Alexandrescu
wrote:
The interesting thing is because of the tight overloading
rules, s will only match statically-sized arrays. So it's
okay to simply expose it as std.array.s without fear it might
clash with other uses of the s symbol.
Kill it with fire. It add language complexity and is not pulling
its weight.
On Friday, 30 January 2015 at 17:06:31 UTC, Nick Treleaven wrote:
On 30/01/2015 17:01, Kenji Hara via Digitalmars-d wrote:
2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d
alias s = staticArray;
auto arr = staticArray(
[[1,2].s],
[[3,4].s, [5,6].s],
[[7,8].s,
On Friday, 30 January 2015 at 18:08:15 UTC, Gary Willoughby wrote:
On Friday, 30 January 2015 at 14:47:22 UT
We don't want the situation of C++ where people only use 80% of
it's features and that 80% is different for everyone. I've
recently been writing some Go code and it's become clear to
On Saturday, 31 January 2015 at 05:21:08 UTC, an wrote:
On Saturday, 31 January 2015 at 05:07:35 UTC, Kapps wrote:
With a library method of [1, 2, 3].s, or syntax of [1, 2, 3]s,
would this proposed $ syntax really provide any benefit? Since
you could already use 'auto a = [1, 2, 3]' for size
On Saturday, 31 January 2015 at 05:07:35 UTC, Kapps wrote:
On Friday, 30 January 2015 at 19:07:53 UTC, Andrei Alexandrescu
wrote:
The interesting thing is because of the tight overloading
rules, s will only match statically-sized arrays. So it's
okay to simply expose it as std.array.s
On 1/30/15 11:00 PM, eles wrote:
On Friday, 30 January 2015 at 18:08:15 UTC, Gary Willoughby wrote:
On Friday, 30 January 2015 at 14:47:22 UT
We don't want the situation of C++ where people only use 80% of it's
features and that 80% is different for everyone. I've recently been
writing some
As discussed in this forum, Kenji has authored
https://github.com/D-Programming-Language/dmd/pull/3615 which has been
recently merged.
By this I am proposing we revert that decision, and quickly - before
2.067 is released lest we'll need to support it forever. Here's why.
One simple litmus
73 matches
Mail list logo
