Re: Simple casting?
On Wednesday, 27 November 2019 at 14:40:56 UTC, Timon Gehr wrote:
On 27.11.19 11:43, ixid wrote:
On Tuesday, 26 November 2019 at 16:33:06 UTC, Timon Gehr wrote:
import std;
void main(){
int[] x=[1,1,2,3,4,4];
int[][] y=x.chunkBy!((a,b)=>a==b).map!array.array;
writeln(y);
}
This stuff is a nightmare for less experienced users like
myself, I wish there were a single function that would make
any data obkect eager, no matter how convoluted its arrays of
arrays of arrays.
import std;
auto eager(T)(T r){
static if(isInputRange!T) return r.map!eager.array;
else return r;
}
void main(){
int[] x=[1,1,2,3,4,4];
int[][] y=x.chunkBy!((a,b)=>a==b).eager;
writeln(y);
}
Thank you, this is great but it should be in Phobos!
Re: Simple casting?
On Tuesday, 26 November 2019 at 16:33:06 UTC, Timon Gehr wrote:
import std;
void main(){
int[] x=[1,1,2,3,4,4];
int[][] y=x.chunkBy!((a,b)=>a==b).map!array.array;
writeln(y);
}
This stuff is a nightmare for less experienced users like myself,
I wish there were a single function that would make any data
obkect eager, no matter how convoluted its arrays of arrays of
arrays.
Re: No UFCS with nested functions?
On Monday, 4 November 2019 at 20:46:41 UTC, H. S. Teoh wrote:
On Mon, Nov 04, 2019 at 07:51:26PM +, Tobias Pankrath via
Digitalmars-d-learn wrote:
Why does the following not work? It works, if I move the
'prop' out of 'foo'.
UFCS is only supported for module-level functions, as far as I
know.
---
struct S {
ubyte[12] bar;
}
bool foo (ref S s)
{
static bool prop(const(ubyte)[] f) {
return f.length > 1;
}
return s.bar[].prop;
}
---
[...]
T
Is this a necessary limitation? It feels inconsistent and clunky.
Re: Accuracy of floating point calculations
On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote:
On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak
wrote:
If you use gdc or ldc you will get same results as c++, or you
can use C log directly:
import std.stdio;
import std.math : pow;
import core.stdc.math;
void main()
{
writefln("%12.3F",log(1-0.)/log(1-(1-0.6)^^20));
}
AFAIK dmd use real for floating point operations instead of
double
Given x87 is deprecated and has been recommended against since
2003 at the latest it's hard to understand why this could be seen
as a good idea.
Re: Automatic variable declaration
On Wednesday, 15 August 2018 at 14:58:40 UTC, Everlast wrote: Many times one must create a variable before a function call: int x = 3; foo(x); writeln(x); and this is fraught with problems such as dependencies(move or change the second line and one has to validate how the first line is affected along with all the others). A new an improved technique, which consolidates the two lines in to one is to automatically have the compiler define the variable: foo(x = 3); writeln(x); // x was implicitly created in this scope by foo. Couldn't you do what you need to do with UFCS and possibly a tee function if you need to add things like writeln into the chain that don't pass the data on?
Re: Enum and CTFE function call
On Tuesday, 14 August 2018 at 13:38:16 UTC, Everlast wrote: etc Thanks all for the comprehensive responses. I was not clearly separating CTFE and the compilation of the function in thinking about it. Much clearer now.
Re: Enum and CTFE function call
On Tuesday, 14 August 2018 at 09:12:30 UTC, ixid wrote: This will not compile as it says n is not known at compile time... This does work if 'value' is changed to immutable and fun to accept it. So it still seems like a missed opportunity as enum shouldn't be able to change either.
Enum and CTFE function call
This will not compile as it says n is not known at compile time:
auto fun(int n) {
static foreach(i;0..n)
mixin(i.to!string ~ ".writeln;");
return;
}
enum value = 2;
void main() {
fun(value);
}
But making it a template parameter fun(int n)() and fun!value
will obviously work as will replacing n in the foreach statement
with the enum 'value'. It seems like a missed opportunity that
the enum nature of 'value' does not propagate through the
function call letting the compiler know that 'value'and therefore
n are known at compile time.
Re: Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....
On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote: So, I have finally convinced the C++ world about that! Now if I can only convince the D world :-) (I'm referring to the repeated and endless threads here where people argue that yes, they can recover from programming bugs!) It seemed like you were perhaps talking at crossed purposes a little on that. You seemed to advocate blowing up the whole world when anything went wrong while some people were making the point that in some contexts while one bit might explode you could need to keep other things going.
Re: Found on proggit: simple treap language benchmark, includes D
On Saturday, 19 May 2018 at 15:09:38 UTC, Joakim wrote: D does well, comes in second on Mac/Win/linux: https://github.com/frol/completely-unscientific-benchmarks https://www.reddit.com/r/programming/comments/8jbfa7/naive_benchmark_treap_implementation_of_c_rust/ Can any experts improve this to come first? That's how you win hearts and minds.
Re: Benchmark Game
On Thursday, 17 May 2018 at 08:51:39 UTC, rikki cattermole wrote: On 17/05/2018 8:50 PM, Chris wrote: For what it's worth, I came across this website: https://benchmarksgame-team.pages.debian.net/benchmarksgame/ D is not there. Anyone interested, if it's worth it? It isn't happening /thread. Isn't it being hosted by a different person now? So it could happen.
Re: Infer return type from assignment
On Wednesday, 11 April 2018 at 14:33:06 UTC, Adam D. Ruppe wrote: On Wednesday, 11 April 2018 at 14:26:53 UTC, ixid wrote: Is it possible to infer a template's return type from what it's assigned to? If not is this a difficult or worthless feature to add? Not really. The function call needs to make sense by itself: fun(a) needs to be a complete thing for a lot of things in the language to work. Type checking assumes it is there, inference assumes it is there, overloading assumes it s there, etc. void foo(int); void foo(float); foo(fun(a)); // what happens? So I don't say anything is impossible that isn't a paradox... but the effort level to solve all these problems would be really high for D. I am sure there are all sorts of thorns involved but for your example a somewhat arbitrarily defined fallback hierarchy of types from most complex to most simple, with it matching the most 'simple' that it can.
Infer return type from assignment
Is it possible to infer a template's return type from what it's
assigned to? If not is this a difficult or worthless feature to
add?
OUT fun(IN, OUT)(IN value) {
return value.to!OUT;
}
void main() {
float a = 5.0;
int b = fun(a);
}
Re: Tuple DIP
On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote: auto (a, b) = (1, 2); For the assignment and unpacking grammar why not adopt the more streamlined Go syntax? auto a, b = 1, 2; // Creates two new variables with the values 1 and 2 auto c, d = 1, (2,3); // A normal variable and a tuple This would seem a lot clearer than: auto (a, b) = (1,2); auto (c, d) = (1, (2,3));
Re: See docs compiler message
On Tuesday, 6 March 2018 at 14:50:05 UTC, ixid wrote: On Tuesday, 6 March 2018 at 14:37:27 UTC, Steven Schveighoffer wrote: Now, there aren't actually docs for Transposed, but you can find it if you look at std.range.transposed: https://dlang.org/phobos/std_range.html#transposed -Steve Thanks, I had found that but that is not an explanation unless you have a lot of prior technical understanding of what save is and why it's not working. I guess it's a general doc quality issue - unless you're already very knowledgeable it's pretty much useless to understand the problem you have. I transposed a range of ranges to pass to a function to get the distance between characters in strings. That works fine, as does printing the result. But it then complains if I try to do anything like fold with the result. What is the correct way to iterate a range of ranges as transposed does?
Re: See docs compiler message
On Tuesday, 6 March 2018 at 14:37:27 UTC, Steven Schveighoffer wrote: Now, there aren't actually docs for Transposed, but you can find it if you look at std.range.transposed: https://dlang.org/phobos/std_range.html#transposed -Steve Thanks, I had found that but that is not an explanation unless you have a lot of prior technical understanding of what save is and why it's not working. I guess it's a general doc quality issue - unless you're already very knowledgeable it's pretty much useless to understand the problem you have. I transposed a range of ranges to pass to a function to get the distance between characters in strings. That works fine, as does printing the result. But it then complains if I try to do anything like fold with the result.
See docs compiler message
/opt/compilers/dmd2/include/std/algorithm/iteration.d(663): Deprecation: function `std.range.Transposed!(string[], cast(TransverseOptions)0).Transposed.save` is deprecated - This function is incorrect and will be removed November 2018. See the docs for more details. If it's going to say 'See the docs' how about linking the docs or even just specifying which docs it's referring to?
Re: dip1000 state
On Saturday, 3 March 2018 at 09:04:04 UTC, Walter Bright wrote: On 3/2/2018 10:48 PM, Manu wrote: I've been arguing for DIP1000 (or something very much like it) for almost 10 years. It's one of the small handful of issues that lead me to the forum in the first place. 'Patience' might not be the right word at this point ;) It is nice to see some interest in it. I've felt like I've been pushing against a wall of indifference for a couple years on it. The good news is: 1. it's implemented 2. it works 3. it's effective The bad news is: 1. it's viral like const is. Ya gotta commit to it! 2. Phobos is not completely dip1000 compatible, but it's pretty close. Druntime is fully dip1000. Might it be worth you or Andrei trying to get Kenji back?
Re: short s, t; t = -s: no (longer) works: Deprecation: integral promotion not done for -s, use
On Saturday, 24 February 2018 at 20:07:04 UTC, kdevel wrote:
I don't get the point of the deprecation message:
--- intprom.d
import std.stdio;
void main ()
{
short s, t;
t = -s;
}
---
$ dmd intprom.d
intprom.d(6): Deprecation: integral promotion not done for -s,
use '-transition=intpromote' switch or -cast(int)(s)
What shall I do in order to get my template code
void mymain (T) ()
{
:
b[i] = -b [i];
:
}
compiled for any type for which negation is defined?
It's ridiculous and is going to cause endless pain and spammed or
forgotten casts in generic code. It will turn off newbies to D.
Re: How to instantiate a template struct with a template constructor without relying on auto deduction?
On Wednesday, 21 February 2018 at 14:42:56 UTC, Simen Kjærås
wrote:
On Wednesday, 21 February 2018 at 14:29:38 UTC, ixid wrote:
I do not understand what is happening here, I tried to wrote
what I thought would be the answer. If someone could explain
that would be great. I wrote this code:
struct Foo2(T, S) {
T bar;
this(S s) {
bar = s.to!T;
}
}
void main() {
float some_float = 0.5f;
int some_int = 1;
auto foo1 = Foo2!(int, float)(some_float);// Compiles, OK!
auto foo2 = Foo2!(int, float)(some_int); // Compiles,
wat?
}
int n = 1;
float f = n; // Basically this.
Foo2!(int, float) expects a float, and ints are implicitly
convertible to float.
--
Simen
Ah yes, that was silly of me to forget. Thanks!
Re: How to instantiate a template struct with a template constructor without relying on auto deduction?
On Wednesday, 21 February 2018 at 14:11:10 UTC, ParticlePeter
wrote:
struct Foo(T) {
T bar;
this(S)(S s) {
bar = convert(s);
}
}
auto foo = Foo!int(some_float);
this works because S is deduced as typeof(some_float), but how
would I instantiate the struct without relying on auto
deduction?
Suppose we would have this kind of constructor where auto
deduction is not possible:
this(int n)(float f) {
static foreach( i; 0..n) { do_some_ctfe_magic;}
}
How to instantiate Foo then?
I do not understand what is happening here, I tried to wrote what
I thought would be the answer. If someone could explain that
would be great. I wrote this code:
struct Foo2(T, S) {
T bar;
this(S s) {
bar = s.to!T;
}
}
void main() {
float some_float = 0.5f;
int some_int = 1;
auto foo1 = Foo2!(int, float)(some_float);// Compiles, OK!
auto foo2 = Foo2!(int, float)(some_int); // Compiles, wat?
}
Re: import strangeness with std.stdio.write
On Tuesday, 13 February 2018 at 13:52:37 UTC, rikki cattermole wrote: write exists in both, writeln exists only in std.stdio. Use named imports to pick which write you want. It does seem a little silly to have a name clash with such a commonly used function. Would it not be better to rename std.file.write to something like writeFile and deprecate the current name?
Re: A betterC base
On Thursday, 8 February 2018 at 15:51:38 UTC, Adam D. Ruppe wrote: On Thursday, 8 February 2018 at 15:43:01 UTC, ixid wrote: That's been said over and over and the message has not gotten through. It is almost never said! We always play by their terms and implicitly concede by saying "but we can avoid it" or "look -betterC". Reddit invades our space, and we fall back. Rust assimilates entire worlds, and we fall back. Not again! The line must be drawn here! This far, no further! You're preaching to the choir here. Being able to add GC easily to a betterC base gives you the same utility and a much stronger story to tell people, optional GC sounds good. Do you really think sticking with the current course on GC would gain more users than very slightly changing tack and making it something you add to a simpler base? I think the second of those will gain more users.
Re: A betterC base
On Thursday, 8 February 2018 at 14:56:31 UTC, Adam D. Ruppe wrote: ooh better last sentence D's GC implementation follows in the footsteps of industry giants without compromising experts' ability to realize maximum potential from the machine. That's been said over and over and the message has not gotten through. With a pay for what you use approach the GC is just as available as it is now, and yes, I completely agree it's very useful and that the reaction to it is ludicrous. This is an illogical argument that we've lost so needs a new approach.
A betterC base
How difficult would it be for D at this point to move towards a pay for what you use system that out of the box is betterC and requires the garbage collector to be explicitly imported? It feels like D has not overcome at least two major issues in the public mind, the built-in GC and, more ludicrously, the D1 library split. Would there not be significant value in making this a D3 transition? As non-breaking as possible but moving the run time elements into libraries and potentially taking the opportunity to invert the defaults for things like safe and pure. The story of this D3 transition to the public would then address the 'issues' head on, creating an easily conveyable story that these have been resolved. This appears to be the level on which a lot of language adoption works, at least between hearing about and trying a language. At the moment it's painful to see the endless criticisms of the GC and library split crop up whenever D is discussed. D is progressing technically but needs a 'story'.
Re: Community Rant
On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote: various. Out of interest did you pick up D before or after joining the start up? If before did you introduce D to them or were they already using it?
Re: jai-like CTFE string formating
On Saturday, 12 August 2017 at 11:47:10 UTC, Stefan Koch wrote:
Whereas the following alternative takes 20 ms :
{
import ctfe_utils;
pragma(msg, format_jai("Hello % % % % % % % % %", " I ", "
just", " have" , " to", " concat", " a lot", " of", " strings
...", 9));
}
see for yourself:
https://www.youtube.com/watch?v=T0BJxdt61RY
Could we not improve the syntax to something like:
pragma(msg, format_jai("Hello %9", " I ", "
just", " have" , " to", " concat", " a lot", " of", " strings
..."));
}
Or whatever is closest that doesn't step on the current print
syntax.
Re: Deprecate real
On Friday, 30 June 2017 at 10:49:19 UTC, Stefan Koch wrote: On Friday, 30 June 2017 at 10:44:41 UTC, ixid wrote: On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson wrote: On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote: Are there any reasons not to put real on the path to removal? The hardware is deprecated by both Intel and AMD and it seems like an unnecessary source of confusion. Don't forget that real is only fp80 on x86. On AArch64(?) it is/should be fp128 which _is_ supported, there is also PowerPC double double. Isn't it an objective of D to move away from such confusing types and have defined widths? D does have well defined floating point types. float and double. real is a special type for people who know what they are dong. And not to be removed. In that case should it not be defined to be something other than 80 bit doubles on x86?
Re: Deprecate real
On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson wrote: On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote: Are there any reasons not to put real on the path to removal? The hardware is deprecated by both Intel and AMD and it seems like an unnecessary source of confusion. Don't forget that real is only fp80 on x86. On AArch64(?) it is/should be fp128 which _is_ supported, there is also PowerPC double double. Isn't it an objective of D to move away from such confusing types and have defined widths?
Deprecate real
Are there any reasons not to put real on the path to removal? The hardware is deprecated by both Intel and AMD and it seems like an unnecessary source of confusion.
Re: dmd -betterC
On Tuesday, 20 June 2017 at 09:21:05 UTC, Walter Bright wrote: On 6/20/2017 2:00 AM, ixid wrote: How far away from a purely additive, pay for what we use situation are we? It would seem like D should be BetterC out of the box, without needing any switches and as you add and use specific features and libraries it builds from that. As long as the compiler supports separate compilation, it has to emit certain information that may or may not be used by other modules. For example, the list of imported modules, which is used by the startup code to determine the order of static construction. The compiler cannot know which of those will have static constructors and which won't. How much of that could be made lazy?
Re: dmd -betterC
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote: Is getting a whole lot better: https://github.com/dlang/dmd/pull/6918 You can now build D executables that do not link in anything from Phobos - only from the standard C library. How far away from a purely additive, pay for what we use situation are we? It would seem like D should be BetterC out of the box, without needing any switches and as you add and use specific features and libraries it builds from that.
Re: I'm Dumpin' it!
On Friday, 12 May 2017 at 12:55:37 UTC, Seb wrote: Hi all, last year there has been a discussion about adding a utility method for easily dumping variables during debugging to Phobos [3971]. The effort stalled and after a couple of months I tried to reboot it [4318]. Now this PR got stalled as well and I am rethinking the work. I think dump!(x, y) already got pretty close to the ideal solution and as we probably aren't going to add a new keyword or language feature for this, I think this is the best what we can get atm. I think the word dump would be too confusing for users based on the history of the term in C. It should be writeFormattedVariableLn. /sarcasm. Just parodying the frankly ridiculous response to 'print'.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
On Thursday, 30 March 2017 at 06:53:47 UTC, XavierAP wrote: On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote: Is that an acceptable tradeof ? I would consider this harmful... The spec already states this about unit tests, so I'd guess the decision was taken in the past conscientiously. If you're worried about compilation time, you can always define your unit tests in separate files that are included for compilation only when needed. Why is it harmful (actually asking, not telling you you're wrong)? I thought we were going to use a pay for what you use philosophy, if a unit test is not run then why is it paid for?
Re: Why don't you advertise more your language on Quora etc ?
On Wednesday, 1 March 2017 at 18:37:46 UTC, Nick Sabalausky (Abscissa) wrote: On 03/01/2017 12:25 PM, Jack Stouffer wrote: I agree. We have a lot to improve in terms of marketing. Mainly our messaging is jumbled. Rust = memory safety Go = the best runtime around D = everything I guess? And the problem is that D is good at everything (IMO), so how do we go about marketing to everyone without getting our messages mixed up in the public's view. Yea, its kinda depressing that programmers will be cold towards D, and admit flat-out it's because D *isn't* a one-trick pony centered around once single gimmick. (I've encountered that myself. Such a facepalm inducer. "Polyglot programming" has rotted people's brains.) We need a powerful message that resonates. I think performance is the strongest message and it directly attacks people's major and misplaced concern about D's garbage collector.
Re: What about this logo ":D" to advertise the D language ?
On Thursday, 2 March 2017 at 09:05:43 UTC, Jared Jeffries wrote: I'm not completely joking ;) D deserves a lot more fame, because it really allows programmers to "develop with a smile", so maybe the logo and slogan should reflect it... With D you can get the job done, as with C++, Java, C#, Node.js etc, but easier, faster, safer and with a lot more pleasure ! D is really good at this, hence the logo :D Yes, that's much better than the Mars and moons effect, I don't think many people who weren't told what it is would guess.
Re: A better way to deal with overloading?
On Friday, 27 January 2017 at 09:47:48 UTC, Bauss wrote: On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis wrote: Many times we pass compound types(non-primitives) as arguments to functions. [...] This is going to be a no from me. It's just another syntactic sugar that doesn't really have a purpose, but more syntactic confusion. We have enough of that stuff in D if you ask me. Out of interest what syntactic sugar would you remove?
Re: alias and UFCS
On Tuesday, 24 January 2017 at 20:51:49 UTC, Stefan Koch wrote: On Tuesday, 24 January 2017 at 16:41:12 UTC, ixid wrote: On Tuesday, 24 January 2017 at 16:27:50 UTC, ixid wrote: On Tuesday, 24 January 2017 at 15:57:48 UTC, Las wrote: On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote: [...] Submit a bug report then. I will if it turns out the behaviour is wrong, that's what I'm checking at this stage. =) Apologies for the extra post - does the alias function count as declared in the same scope as the content of the function? That would be plausible as UFCS refuses to work on functions declared in the same scope. Is this something that could be changed? UFCS is only applied if the function if defined at module scope. This to to prevent the meaning of a ufcs function from changing. Does alias of an existing function count as a new function definition in that case?
Re: alias and UFCS
On Tuesday, 24 January 2017 at 16:27:50 UTC, ixid wrote:
On Tuesday, 24 January 2017 at 15:57:48 UTC, Las wrote:
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
This code:
T tFunc(alias F, T)(T n) {
n.F;
return n;
}
Produces this error:
Error: no property 'F' for type 'int[]' (or whatever type I
use).
The alias rules for functions seem to be incompatible with
UFCS, F(n) works fine. What are the rewrite steps here? Is
this necessary or an oversight? Not very uniform function
call syntax.
Submit a bug report then.
I will if it turns out the behaviour is wrong, that's what I'm
checking at this stage. =)
Apologies for the extra post - does the alias function count as
declared in the same scope as the content of the function? That
would be plausible as UFCS refuses to work on functions declared
in the same scope. Is this something that could be changed?
Re: alias and UFCS
On Tuesday, 24 January 2017 at 15:57:48 UTC, Las wrote:
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
This code:
T tFunc(alias F, T)(T n) {
n.F;
return n;
}
Produces this error:
Error: no property 'F' for type 'int[]' (or whatever type I
use).
The alias rules for functions seem to be incompatible with
UFCS, F(n) works fine. What are the rewrite steps here? Is
this necessary or an oversight? Not very uniform function call
syntax.
Submit a bug report then.
I will if it turns out the behaviour is wrong, that's what I'm
checking at this stage. =)
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On Friday, 11 September 2015 at 21:16:06 UTC, Brian Schott wrote: On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir Panteleev wrote: Apparently it was decided at DConf 2015 to remove std.stream and friends from Phobos. Kill it with fire. Speaking of killing things with fire (OT) - what's happening with the comma operator? I want delicious tuples like Go.
Re: Red Hat's issues in considering the D language
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Thanks, Andrei What is the story over the ownership of DMD's backend? I believe Walter's former employer has some stake in it. Has Walter spoken to them about them donating whatever rights they have to the D foundation?
Re: Nov 16 - Memory Safety and the D Programming Language
On Sunday, 20 November 2016 at 22:34:26 UTC, Walter Bright wrote: On 11/14/2016 1:39 AM, qznc wrote: On Monday, 14 November 2016 at 06:57:07 UTC, Walter Bright wrote: · Follow our YouTube channel. So, there will be a recording? Great! Unfortunately, the audio was lost 18 minutes in. Looks to be not worth posting. I do have the slides up, though. http://www.walterbright.com Would it be worth the D Foundation investing in a good portable setup for recording people's talks? Certainly for the main D conference but also for the core team members and other VIPs. There is considerable value in high quality recordings being available. The quality of some previously has been very poor due to the limitations of the equipment available. Also some shared guidance about how to record a talk effectively.
Re: Why doesn't std.variant.visit automatically call the provided delegates?
On Saturday, 5 November 2016 at 20:22:13 UTC, Adam D. Ruppe wrote:
On Saturday, 5 November 2016 at 20:15:14 UTC, Kapps wrote:
That feels like it should be a compiler warning.
I'm now of the opinion that the {} delegates should be
deprecated (instead use () {} delegates)... this comes up a lot
and there's a few other places too where it is a pain... and it
isn't that worth keeping imo.
Have you discussed this with Andrei or Walter? It would be a good
change.
Re: If Statement with Declaration
On Friday, 4 November 2016 at 00:04:28 UTC, mogu wrote: Introducing a block is not intuitive and cause an identation. How is using a block to produce a sub-scope not intuitive? That's using a standard feature to do exactly what it is supposed to do.
Re: consequences of removing semicolons in D like in Python
On Saturday, 17 September 2016 at 11:59:53 UTC, cym13 wrote: Note how a leading dot means “global scope” but a dot after something means UFCS or method/attribute. What should this program do? If it is akin to “auto i = [1, 2, 3]; .filterEven();” then i is an int[] and the program prints “Nothing here”. But if it is understood as “auto i = [1, 2, 3].filterEven();” then i is whatever type filter returned and nothing is printed. Entirely aside from removing semi-colons or not the global dot operator needs to be killed with fire and replaced with something more explicit. It's far too rarely used to justify such an easily confused and meaningless grammar.
Re: C# 7 Features - Tuples
On Thursday, 25 August 2016 at 13:41:29 UTC, dom wrote: https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/ came across the new c# features today. I really liked the syntax for Tuples (and deconstructors), would be great to have a similar syntax in D :) This is fantastic, hopefully we can have this syntax in D.Ultimately it would be nice if we could move towards the rest of the C-style tidy ups that are becoming more commonly used but I know this community is pretty conservative. Optional semi-colons, no parens on if, while etc and enforced curly braces. Also := being a synonym for auto assignment.
Re: Compiling DMD on Windows: A journey of mystery and madness
On Monday, 22 August 2016 at 02:34:37 UTC, Walter Bright wrote: On 8/21/2016 12:12 PM, Andrei Alexandrescu wrote: How does that work? Aren't step-by-step documents "how to do this on Posix" and "how to do this for Windows" best tested in one environment at a time? I know when I'm following step-by-step procedures, I prefer it to be specific to my case, not a catch-all one with callouts for other cases melded in. Some users might just about know they're on Windows but have no idea what Posix is so won't know to ignore those parts or will at least be confused and intimidated. The path into using things needs to be as easy as possible.
Re: Why D isn't the next "big thing" already
On Wednesday, 27 July 2016 at 00:52:30 UTC, Gorge Jingale wrote: So, you can see D as a sort of dried up waste land desert with a few nice palm trees growing here and there and a few scorpions. C++, say, is a very lush forest with many tree dwelling monkeys. Which environment would you rather use? You're forgetting the spiked stick pits that the lush forest is full of, and also the monkeys are rabid. =)
Re: DIP: Tail call optimization
On Monday, 11 July 2016 at 11:19:59 UTC, Dicebot wrote: D language authors don't want to enforce any code of conduct or moderation in the newsgroup which means certain personas have to be simply ignored. This is not a policy that will scale well. Ketmar's behaviour was badly out of line. People need to save the scathing pseudo-Linus stuff for the inner-circle rather than new comers.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:17:08 UTC, ketmar wrote: your DIP is aimed for is brain-damaged coders who are not able to understand how programs work (and why "scope(exit)" may prevent TCO). it won't help anyone. sorry. This is really unacceptablely rude. Step away from the computer and cool off.
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 09:09:13 UTC, Mike Parker wrote: Where does this impression come from that Windows is a second-class citizen? So... what's the problem? I'm saying things like that is where the impression can come from. It's not a problem now.
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 07:44:22 UTC, Mike Parker wrote: Where does this impression come from that Windows is a second-class citizen? 64-bit support seemed to take forever to reach Windows.
Re: Why I won't fix phobos bugs anymore
On Friday, 3 June 2016 at 05:51:02 UTC, Pie? wrote: Also, Sisyphus must not have been too crafty! If he spend all that time digging out the hill then it would have been lower in gravity and he wouldn't have to carry it for eternity... just give it a nudge and it would roll down. Hen he could use all that dirt to build a barricade to keep the boulder from rolling away(unless it could magically go through the dirt). I think a part of the point of the myth is that everything is returned to its previous state over night, including earthworks.
Re: Operator overloading through UFCS doesn't work
On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote: And the fact that allowing free functions to overload operators via UFCS sends us into that territory just highlights the fact that they're a horrible idea. - Jonathan M Davis Do you have any examples of UFCS doing bad things? Most people seem to very much like it yet you argue against any change that would benefit UFCS. You seem to prefer: read(to(easier(much(i over i.much.easier.to.read
Re: Split general into multiple threads
On Thursday, 26 May 2016 at 17:07:54 UTC, Seb wrote: I think we all agree that general is having to much traffic and according to CyberShadow [1] this again is just an approval issue, however I expect this a bit controversial, so please no OT! Only other category proposals. Proposed categories: - DMD - DRuntime - Phobos - Language design (or Idea pool) - D Foundation + resources - Events - Other (formerly known as General) I want to stress that whatever categories we pick, we have to adapt them anyways if we realize that something is noisy again or too silent. https://github.com/CyberShadow/DFeed/issues/66 That's far too many categories, it would be better to have General and Technical at this stage.
Re: Our Sister
On Thursday, 26 May 2016 at 16:20:37 UTC, Adam D. Ruppe wrote: On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote: I've been working on RCStr (endearingly pronounced "Our Sister") You really should actually mention RCStr in the subject line so people overwhelmed with the staggering amount of off topic chatter on this forum don't disregard this thread too. To be fair using a forum called 'General' for technical discussion is asking for trouble. We will be able to tell when D actually starts to become popular because this part of the forum will cease to function as it's inundated with newbies who expect it to mean general questions or something similar.
Re: Idea: swap with multiple arguments
On Tuesday, 24 May 2016 at 01:18:05 UTC, Jonathan M Davis wrote: Hmmm. And I would have assumed that it rotated in the other direction. This is really going to need a very specific name like rotateLeft or rotateRight in order for it not to be error-prone. - Jonathan M Davis Why would you assume it would rotate left? As a general rule to avoid verbosity we could have a default assumption of things moving in one direction and the inverse gets named. So we would have rotate and rotateLeft.
Re: OpenGL with D tutorials
On Sunday, 22 May 2016 at 12:55:47 UTC, Guillaume Piolat wrote: On Sunday, 22 May 2016 at 12:13:07 UTC, ixid wrote: What is the best OpenGL tutorial with D to use? I've tried to use d-gamedev-intro and opengl-tutorials and seem to get errors, files that are no longer included are needed (dgl)? and deprecation messages. Not a tutorial by any means but this example program can get you started with the annoying "Modern" OpenGL: https://github.com/d-gamedev-team/gfm/blob/master/examples/simpleshader/simpleshader.d Thanks, I have tried to get all the libraries and link them and now get a huge number of error messages (I am almost certainly missing or have mis-installed something, it doesn't complain about failing to import anything though. SeverityCodeDescription Project FileLineSuppression State Error Error 42: Symbol Undefined _D3gfm4sdl26window10SDL2Window11swapBuffersMFZv (void gfm.sdl2.window.SDL2Window.swapBuffers()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict7opengl39functions7glClearPWNbNikZv C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl23sdl4SDL213processEventsMFZv (void gfm.sdl2.sdl.SDL2.processEvents()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram3useMFZv (void gfm.opengl.program.GLProgram.use()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl3vao5GLVAO6unbindMFZv (void gfm.opengl.vao.GLVAO.unbind()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram5unuseMFZv (void gfm.opengl.program.GLProgram.unuse()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict7opengl39functions10glViewportPWNbNiZv C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl28keyboard12SDL2Keyboard9isPressedMFiZb (bool gfm.sdl2.keyboard.SDL2Keyboard.isPressed(int)) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl26window10SDL2Window8setTitleMFAyaZv (void gfm.sdl2.window.SDL2Window.setTitle(immutable(char)[])) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram7uniformMFAyaZC3gfm6opengl7uniform9GLUniform (gfm.opengl.uniform.GLUniform gfm.opengl.program.GLProgram.uniform(immutable(char)[])) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl23sdl4SDL28keyboardMFZC3gfm4sdl28keyboard12SDL2Keyboard (gfm.sdl2.keyboard.SDL2Keyboard gfm.sdl2.sdl.SDL2.keyboard()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4math6matrix21__T6MatrixTfVii4Vii4Z6Matrix8identityFNaNbNiNfZS3gfm4math6matrix21__T6MatrixTfVii4Vii4Z6Matrix C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict4sdl29functions12SDL_GetTicksPUNbNiZk C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\
OpenGL with D tutorials
What is the best OpenGL tutorial with D to use? I've tried to use d-gamedev-intro and opengl-tutorials and seem to get errors, files that are no longer included are needed (dgl)? and deprecation messages.
Re: Always false float comparisons
On Wednesday, 18 May 2016 at 11:38:23 UTC, Manu wrote: That's precisely the suggestion; that compile time execution of a given type mirror the runtime, that is, matching precisions in this case. ...within reason; as Walter has pointed out consistently, it's very difficult to be PERFECT for all the reasons he's been repeating, but there's still a massive difference between the runtime executing a bunch of float code, and the compile time executing it all promoted to 80bits. Results will drift apart very quickly. What do you think can be productively done to improve the situation? I am beginning to think a Wiki-like structure would be better for these discussions where each major debater has their thoughts on a specific issue in a relevantly headed section so there is more clarity.
Re: Always false float comparisons
On Wednesday, 18 May 2016 at 08:55:03 UTC, Walter Bright wrote: On 5/18/2016 1:30 AM, Ethan Watson wrote: You're also asking for a mode where the compiler for one machine is supposed to behave like hand-coded assembler for another machine with a different instruction set. Actually, I'm asking for something exactly like the arch option for MSVC/-mfmath option for GCC/etc, and have it respect that for CTFE. MSVC doesn't appear to have a switch that does what you ask for: https://msdn.microsoft.com/en-us/library/e7s85ffb.aspx Apologies if this has been addressed in the thread, it's a difficult structure to follow for technical discussion. You seem positive about software implementations of float. What are your thoughts on having the compile time implementation of a given type mirror the behaviour of the runtime version? Fundamentally whatever rules are chosen it would seem better to have fewer rules for people to remember.
Re: dpaste and warning upon leaving page
On Wednesday, 11 May 2016 at 11:27:44 UTC, nazriel wrote: On Tuesday, 10 May 2016 at 16:39:05 UTC, Anonymouse wrote: I just had a PEBCAK moment where I was composing a large-ish snippet on dpaste, then accidentally left the page by clicking the back button on my mouse. Going back to the page I see my changes were lost. Could we maybe add a warning when leaving the page if the content has been changed? I think it's the onbeforeunload event, but I don't know javascript well. http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_onbeforeunload_dom Good idea. I've added it to TODO list here https://github.com/nazriel/dpaste-frontend/issues/3 Could the layout be modified for mobile screens so the compile button appears close to the text entry box? At present the compiler options box goes below the options box and requires a fair bit of scrolling just to hit the compile button. dpaste is a really nice way of playing with minor bits of code on mobile.
Re: Killing the comma operator
On Tuesday, 10 May 2016 at 09:52:07 UTC, Mathias Lang wrote: Do you like comma expressions, and think its presence in the language is more pro than con ? Kill it with fire and hopefully we can have pretty tuple syntax like Swift and Go's.
Re: So, to print or not to print?
On Tuesday, 26 April 2016 at 03:13:22 UTC, Jonathan M Davis wrote:
On Tuesday, April 26, 2016 01:44:07 Jack Stouffer via
Digitalmars-d wrote:
On Monday, 25 April 2016 at 19:35:04 UTC, Andrei Alexandrescu
wrote:
> https://github.com/dlang/phobos/pull/3971
I really don't see the utility of the function over writefln
being great enough to warrant inclusion. I'd vote not to
include it.
I concur. IMHO, it doesn't add enough value to be worth it, and
given that it adds yet another printing function, it'll
increase confusion with newcomers.
- Jonathan M Davis
Please find an example of a newcomer who would be confused by
print. This is an objectionable argument because none of the
people making it are newcomers, you're using an entirely
theoretical newcomer as your argument, and seem to think
'print(a, b, c);' is going to confuse people more than
'writefln("%s %s %s", a, b, c);' which is ridiculous.
Print function names are hardly pristine snow of simplicity that
'print' is going to muddy. What do you think goes through a
newcomer's mind when they see 'writefln'? For the vast majority
it's almost certainly not 'write formatted line', it's 'write
wagarble' and they'll forget wagarble next time they want to use
it.
Print is incredibly simple and a low barrier to entry. When
people need more complexity they can read up on other functions.
You barely need to read anything to use print and you don't need
to recheck the documents for using it the second time. Most users
will find functions like writefln a bit nightmarish when they
just want the program to do the most basic thing to interact with
it in the first place. This has been further compounded by some
of the alternative suggestions where people immediately suggest
turning it into a template function etc.
Yes, you could sugar up everything and turn the language into an
unmaintainable mess, it's a question of effort vs reward.
Barring main, printing something is likely the most commonly used
function and this covers 90% of what people use it for in the
simplest and easiest way. People fall into using languages
because they're elegant, powerful and easy to use. Suddenly all
the little code examples people will be exposed to are that much
clearer and more elegant. The benefit is far greater than the
cost.
Re: So what does (inout int = 0) do?
On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu wrote: We want Phobos to be beautiful, a prime example of good D code. Admittedly, it also needs to be very general and efficient, which sometimes gets in the way. But we cannot afford an accumulation of mad tricks to obscure the large design. Andrei Why didn't we go with all functions being able to infer const, pure etc rather than just templates?
Re: uniform initialization in D (as in C++11): i{...}
On Tuesday, 5 April 2016 at 09:22:12 UTC, Jin wrote:
On Tuesday, 5 April 2016 at 05:39:25 UTC, Timothee Cour wrote:
what's D's answer for C++11's uniform initialization [1] which
allows DRY code?
Could we have this:
struct A{
int a;
int b;
}
A fun(A a, int b) {
if(b==1) return i{0,1};
else if(b==2) return i{2,3};
else return fun(i{3,4}, 1);
}
A fun(A a, int b) {
if(b==1) return [0,1];
else if(b==2) return [a:2,b:3];
else return fun([3,4], 1);
}
Square brackets look better than curly brackets which create a
lot of visual noise, especially when mixed with other brackets.
It also feels neat to treat tuples like an array of mixed types.
Can't we be more aggressive about reclaiming the comma operator
for tuples?
Re: foreach UFCS
On Thursday, 31 March 2016 at 13:48:27 UTC, Adam D. Ruppe wrote: It is trying to look up a name i in global scope, and calling writeln on it. This is why the .name syntax exists: so you can bypass local variables with the same name when trying to access a global. It would compile if you put an `int i;` at the top of your module... try it! Thanks, that makes sense! I had forgotten the global dot syntax. That seems like a somewhat sketchy syntax given how little one would use it, wouldn't something like: writeln(i).global; be much clearer for globals?
foreach UFCS
What is going on with UFCS and foreach? foreach(i;0..5).writeln; This prints five line breaks. foreach(i;0..5).i.writeln; This will not compile. foreach(i;0..5).writeln(i); This writes out 1 to 4 on separate lines. Is this supposed to work? I thought a.b would be rewritten to b(a) with UFCS but writeln(foreach(i;0..5)) is nonsensical and does not compile and should be the same as foreach(i;0..5).writeln;
Re: Speed kills
On Monday, 15 February 2016 at 13:51:38 UTC, ixid wrote: Every time there is a D thread on reddit it feels like the new user is expecting mind-blowing speed from D. https://www.reddit.com/r/programming/comments/45v03g/porterstemmerd_an_implementation_of_the_porter/ This is the most recent one where John Colvin provided some pointers to speed it up significantly. Walter has done some good work taking the low-hanging fruit to speed up DMD code and there is a lot of effort going on with reference counting machinery but I wondered if some of the common errors people make that slow down D code can be addressed? Literals used to be a hidden speed bump but I think that was improved, now the append operator is one of the most common culprits, can this not be enhanced behind the scenes to work more like append? Do others notice common pitfalls between the article code and what the D community then suggests where we can bridge the gap so naive users get faster code? Since I posted this thread I've learned std.algorithm.sum is 4 times slower than a naive loop sum. Even if this is for reasons of accuracy this is exactly what I am talking about- this is a hidden iceberg of terrible performance that will reflect poorly on D. That's so slow the function needs a health warning.
Re: Simple performance question from a newcomer
On Tuesday, 23 February 2016 at 14:07:22 UTC, Marc Schütz wrote: On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote: We really need to standard algorithms to be fast and perhaps have separate ones for perfect technical accuracy. While I agree with most of what you're saying, I don't think we should prioritize performance over accuracy or correctness. Especially for numerics people, precision is very important, and it can make a just as bad first impression if we don't get this right. We can however make the note in the documentation (which already talks about performance) a bit more prominent: http://dlang.org/phobos/std_algorithm_iteration.html#sum Wouldn't it be better to have technically perfect implementations for those numerics people? Sum is a basic function that almost everyone may want to use, this is a factor of four slowdown for the sake of one user group who could be perfectly well served by a sub-library that contains high-accuracy versions. It might make sense if the speed difference were only a few percent.
Re: Simple performance question from a newcomer
On Monday, 22 February 2016 at 15:43:23 UTC, dextorious wrote: I do have to wonder, however, about the default settings of dub in this case. Having gone through its documentation, I might still not have guessed to try the compiler options you provided, thereby losing out on a 2-3x performance improvement. What build options did you use in your dub.json that it managed to translate to the correct compiler switches? Your experience is exactly what the D community needs to get right. You've come in as an interested user with patience and initially D has offered slightly disappointing performance for both technical reasons and because of the different compilers. You've gotten to the right place in the end but we need point A to point B to be a lot smoother and more obvious so more people get a good initial impression of D. Every D user thread seems to go like this- someone starts with DMD, they then struggle a little and hopefully get LDC working with a list of slightly obscure compiler switches offered. A standard algorithm performs disappointingly for somewhat valid technical reasons and more clunky alternatives are then deployed. We really need to standard algorithms to be fast and perhaps have separate ones for perfect technical accuracy. What are your thoughts on D now? What would have helped you get to the right place much faster?
Re: DigitalWhip
On Saturday, 13 February 2016 at 21:10:11 UTC, Adam D. Ruppe wrote: We should run benchmarks with bounds checking enabled to better reflect real world results. Yes, it might "lose" to C Like for like comparisons are the best approach, making it clear what a given result is for. The most effective story for D is that it's fast.
Re: Head Const
On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis wrote: The problem that folks frequently want to be able to solve that they simply cannot solve >with D's const (and headconst wouldn't help) is that they want to be able to pass an object >to a function that takes it as const or return a const object from a const member function >and have stuff like reference counting, caching, mutexes, etc. work - stuff that has to be >part of the object (at least in pure code) but which isn't part of its logical state and >cannot be const. Is it not possible to have two objects, the data and the information about the data? It seems like a mistake to try to treat metadata as the data. I just ask out of interest as I lack the experience to have a meaningful view, the category confusion between data and metadata seems like a path to excessive complexity.
Speed kills
Every time there is a D thread on reddit it feels like the new user is expecting mind-blowing speed from D. https://www.reddit.com/r/programming/comments/45v03g/porterstemmerd_an_implementation_of_the_porter/ This is the most recent one where John Colvin provided some pointers to speed it up significantly. Walter has done some good work taking the low-hanging fruit to speed up DMD code and there is a lot of effort going on with reference counting machinery but I wondered if some of the common errors people make that slow down D code can be addressed? Literals used to be a hidden speed bump but I think that was improved, now the append operator is one of the most common culprits, can this not be enhanced behind the scenes to work more like append? Do others notice common pitfalls between the article code and what the D community then suggests where we can bridge the gap so naive users get faster code?
Re: Just because it's a slow Thursday on this forum
On Friday, 12 February 2016 at 03:18:47 UTC, Nick Sabalausky
wrote:
I'd be perfectly happy to have it, particularly if it had a
less confusing name, but can definitely see it being debatable
whether it really is Phobos-worthy.
Andrei has previously expressed a desire for a big standard
library and it is a very good introduction to the language for
newbies to be able to use print. It's simple and does what they
expect, writefln("%s %s %s %s", a, b, c, d) is anything but
simple and contains multiple pitfalls for a new user. This is
likely the second most commonly used function (or thing someone
wants a function to do) after main.
Why is the resistance to convenience functions so high in this
community? If you want people to use D it will need to be both
powerful and feel light and easy to use. It would seem to be
better for D to allow convenience functions in Phobos more
broadly where the use case is common.
There are already many print and write functions, it's not a
thing that has only one way to do it that will be greatly muddied
by the addition of another function, can you cite threads from
other languages where people are confused by a function called
print that prints?
Re: Weird issue with std.range.iota.length
On Friday, 12 February 2016 at 15:59:09 UTC, Jonathan M Davis wrote: It would be far better IMHO to just do a check in iota and throw a RangeError if the length wouldn't fit in size_t. Having length ever be anything other than size_t is just going to cause problems with other ranges. On 32-bit systems, you lose out on the ability to have a range that covers all values of long or ulong, but that's of very limited usefulness anyway, and as long as the number of elements is no greater than size_t.max, it would be fine - which would cover virtually all use cases. No, it's not perfect, but allowing length to be anything but size_t just causes bugs - especially in generic code. - Jonathan M Davis What about a template overload where you can set the length type as separate from the type of the range elements?
Re: Just because it's a slow Thursday on this forum
On Tuesday, 9 February 2016 at 18:02:50 UTC, Andrei Alexandrescu wrote: On 02/09/2016 10:34 AM, ixid wrote: An alternate solution is liable to be too clever for its own good. Everybody and their cat understands string concatenation. What we need here is better tactical tools, e.g. a simple string template/interpolation engine. -- Andrei I wasn't suggesting throwing the baby out with the bathwater. Library and IDE support to what's there would be great.
Re: Just because it's a slow Thursday on this forum
On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote: I'm not a fan of non-trivial string mixins except in extenuating circumstances. This is something Steven Schveighoffer commented on in these discussions as well. As this is a fundamental D feature and it's currently rather clunky and hard to use it would suggest this needs improvement. What should be done with it if anything and with what methods?
Re: print function
On Thursday, 4 February 2016 at 22:13:36 UTC, Ola Fosheim Grøstad wrote: Well, it is probably not the best point in time to have absolute beginners use D anyway. That is a ridiculous thing to say and a great way of ensuring a language dies. Good starting resources help everyone.
Re: print function
On Thursday, 4 February 2016 at 11:04:23 UTC, cym13 wrote: On Thursday, 4 February 2016 at 10:18:35 UTC, ixid wrote: Do you think your knowledge and experience is a good model for how a new user who hasn't done much if any programming before would approach this? A design choice had to be made and made it was. Adding another function now (or worse, changing the existing ones) would only bring more confusion for beginners and unconsistency to the language. I firmly believe that no matter what your experience you have having one and preferably only one way to do things is more important to ease the learning process than having spaces or not. That's a nonsensical argument given the number of printing and writing functions that exist.
Re: print function
On Thursday, 4 February 2016 at 10:05:15 UTC, Jonathan M Davis
wrote:
I would normally expect someone to do that with writefln, which
would be cleaner. e.g.
writefln("%s %s %s %s", a, b, c, d);
Personally, I've never felt the need for a function like you're
describing.
- Jonathan M Davis
Do you think your knowledge and experience is a good model for
how a new user who hasn't done much if any programming before
would approach this?
Re: print function
On Thursday, 4 February 2016 at 13:46:46 UTC, Dejan Lekic wrote:
On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote:
It would be nice to have a simple writeln that adds spaces
automatically like Python's 'print' in std.stdio, perhaps
called print.
There are many implementations of string interpolation in D
(that is what you want, basically). One of them is given in
Phillipe's excellent book about templates:
https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/D-templates-tutorial.md#simple-string-interpolation .
I have written an attempt at it but my point was that a print
function would be a good addition to the standard library rather
than asking someone to write an implementation for me.
string makePrintString(T)(T length) {
import std.conv : to;
string s = "writeln(";
foreach( i; 0 .. length) {
s ~= "a[" ~ i.to!string ~ "]";
if(i != length - 1)
s ~= ",\" \",";
else s ~= ");";
}
return s;
}
void print(A...)(A a) {
static if(a.length) {
mixin(makePrintString(a.length));
} else writeln;
}
Re: print function
On Thursday, 4 February 2016 at 17:34:33 UTC, Artur Skawina wrote: On 02/04/16 16:32, Artur Skawina wrote: but that seems too expensive, when the use is just in toy programs and debugging. I hadn't really considered the relative cost-benefit, it's just a habit to try to hardcode things at compile time. =) It certainly seems to make sense to do it that way.
print function
It would be nice to have a simple writeln that adds spaces automatically like Python's 'print' in std.stdio, perhaps called print.
Re: print function
On Thursday, 4 February 2016 at 00:30:03 UTC, cym13 wrote: On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote: It would be nice to have a simple writeln that adds spaces automatically like Python's 'print' in std.stdio, perhaps called print. Sounds way too redundant to me. Normally you'd be right but printing out data is such a common thing, especially for beginners. It's the kind of thing that can make their early experience of a language a lot more positive. writeln(a, " ", b, " ", c, " ", d); Is very clunky. Programming languages are like cereal, you need sugar to get the kids hooked.
Re: reduce -> fold?
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote: As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders. So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Thoughts? Andrei Absolutely yes!
foreach change for multi-dimensional data
This is an idle thought hence putting it on the Learn-level forum. An idea struck me for foreach to make working with more complicated data types or heavily nested data easier. uint[][] a = [[1,2,3],[4,5,6]]; foreach(uint[] b; a) b.writeln; At present you can specify the type of 'b' in this example. If you want to iterate over each uint you have to write (and obviously you can omit the type for 'b' and 'c'): foreach(uint[] b; a) foreach(uint c; b) c.writeln; It would be nice if you could do something like this: foreach(uint c; a) c.writeln; Where it will take the ForeachType of 'a' until it finds a match to the type of 'c' and iterate over all that data. It would make it much less messy to apply a function that takes uint to all the data rather than having to nest loops or map maps.
Re: foreach change for multi-dimensional data
On Thursday, 28 January 2016 at 15:38:20 UTC, Ali Çehreli wrote: On 01/28/2016 05:33 AM, ixid wrote: > This is an idle thought hence putting it on the Learn-level forum. An > idea struck me for foreach to make working with more complicated data > types or heavily nested data easier. > > > uint[][] a = [[1,2,3],[4,5,6]]; [...] > It would be nice if you could do something like this: > > foreach(uint c; a) > c.writeln; It looks like Solomon E's recent collapse() is what we need here: http://forum.dlang.org/post/xihlsfgfpykdvmvrg...@forum.dlang.org foreach(c; a.collapse) // ... Ali That's a much more limited version of what I'm suggesting in that it just collapses until something isn't an array any more, sometimes you might only want to collapse two levels and get up with something that's still an array type or you will be getting members in struct that's in an array. I've written something similar for myself that will collapse until a provided type is matched or the first argument type of a provided function is matched and apply the function.
Re: Collapsing n-dimensional array to linear (1 dimensional)
On Monday, 25 January 2016 at 08:31:14 UTC, abad wrote: On Monday, 25 January 2016 at 02:27:57 UTC, Solomon E wrote: On Saturday, 23 January 2016 at 07:57:55 UTC, Ali Çehreli Ruby's Array class includes this sort method for flattening and for me it was surprisingly useful, for instance when it was necessary to write the array to file. D could certainly add a few more helper functions to work on multidimensional data or perhaps an article, I admit I was unaware joiner could be chained without mapping like that. One that regularly irritates me is arrays of results that you want to make eager such that you can map a lazy function to a 2D array and then store the result in a 2D array again. This seems messy and I'd like a function that will take absolutely anything and force eager assessment. auto a = res.map!array.array; // De-lazying 2D result Would like: auto a = res.eager;
Re: [dlang.org] Let's talk about the logo
On Friday, 22 January 2016 at 19:53:32 UTC, ronaldmc wrote: On Thursday, 21 January 2016 at 23:46:26 UTC, anonymous wrote: The logo is repeatedly being called out as a weak spot of the D brand. But so far Walter has been adamant about keeping it the way it is. I don't want to start a war, but this isn't community? I mean aren't we trying to make things better, because the way you said it seems like a dictatorship. I think a fair explanation would be that it's a meritocracy of effort and ability. Walter has put an enormous amount of effort into D over a long period and therefore his view holds great sway. It's a good system for a project like this generally though it falls down a bit on issues that are more personal preference than technical.
Re: [dlang.org] Let's talk about the logo
On Thursday, 21 January 2016 at 23:46:26 UTC, anonymous wrote: The logo is repeatedly being called out as a weak spot of the D brand. But so far Walter has been adamant about keeping it the way it is. I certainly agree the logo is weak, to me the planets look more like a bad lens flare effect unfortunately. The bottom reflection bit needs to be removed but I think the planets/moons need to be spaced away from the D. The bigger dot overlapping the D just looks messy, like a misplaced paint blotch.
Re: Wishlist for D
On Friday, 11 December 2015 at 10:04:22 UTC, Andrea Fontana wrote: On Tuesday, 1 December 2015 at 16:48:00 UTC, Suliman wrote: Right place is write here My wishes: - Less flamewars. - A heavy template-based image manipulation library (like antigrain for c++) As forums go this one is very calm and reasonable. A long thread disagreeing on an issue isn't a flamewar.
Re: D compiler daily downloads at an all-time high
On Monday, 16 November 2015 at 15:20:51 UTC, Andrei Alexandrescu wrote: That's a new all-times high ever since we started measuring on January 02, 2013. The previous record, 1630 average daily downloads, was established in the four weeks ending November 17, 2014. Andrei That looks more like growth has plateaued which should be extremely concerning.
Re: RFC in Comparison between Rust, D and Go
On Wednesday, 11 November 2015 at 10:49:02 UTC, Ola Fosheim Grøstad wrote: I wish you would streamline template definitions even more in D, though. What were you thinking?
Re: Preventing implicit conversion
On Thursday, 5 November 2015 at 05:41:46 UTC, Jonathan M Davis wrote: On Wednesday, November 04, 2015 21:22:02 ixid via Digitalmars-d-learn wrote: On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin wrote: > On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: >> Is there an elegant way of avoiding implicit conversion to >> int when you're using shorter types? > > Only with library solution. Implicit conversions are built > into language. Doesn't that seem rather limiting and unnecessary? Why? You can't affect what conversions do and don't work for the built-in types in _any_ language that I've ever used, and I've never heard of a language that allowed anything like that. If you want different conversion rules, you need to create a user-defined type that defines the conversions you want. That's pretty normal. And AFAIK, there aren't very many folks trying to avoid the built-in implicit conversions in D, particularly since D eliminated the various implicit narrowing conversions that you get in C/C++. - Jonathan M Davis In C++ I can add two shorts together without having to use a cast to assign the result to one of the two shorts. It just seems super clunky not to be able to do basic operations on basic types without casts everywhere.
Operator implicit conversion difference
This may have been overlooked in my other thread so I wanted to ask again: This seems very inconsistent, does a += b not lower to a = a + b? I guess not based on the below: ushort a = ushort.max, b = ushort.max; a += b; // Compiles fine a = a + b; // Error: cannot implicitly convert expression (cast(int)a + cast(int)b) of type int to ushort
Re: Preventing implicit conversion
On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin wrote: On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? Only with library solution. Implicit conversions are built into language. Doesn't that seem rather limiting and unnecessary?
Re: Preventing implicit conversion
On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? Also does this not seem inconsistent: ushort a = ushort.max, b = ushort.max; a += b; // Compiles fine a = a + b; // Error: cannot implicitly convert expression (cast(int)a + cast(int)b) of type int to ushort
Preventing implicit conversion
Is there an elegant way of avoiding implicit conversion to int when you're using shorter types?
