Re: Is there a way to disable 'dub test' for applications?

On Monday, 18 April 2016 at 05:30:21 UTC, Jonathan M Davis wrote: On Monday, April 18, 2016 04:25:25 Jon D via Digitalmars-d-learn wrote: I have an dub config file specifying a targetType of 'executable'. There is only one file, the file containing main(), and no unit tests. When I run 'dub

Re: Is there a way to disable 'dub test' for applications?

On Monday, April 18, 2016 04:25:25 Jon D via Digitalmars-d-learn wrote: > I have an dub config file specifying a targetType of > 'executable'. There is only one file, the file containing main(), > and no unit tests. > > When I run 'dub test', dub builds and runs the executable. This > is not

Re: Which application is much suited and which is not.

On 04/17/2016 02:33 AM, Suliman wrote: Could you write article about D for Csharp programmers? About D benefits While waiting for that document: :) http://dconf.org/2013/talks/wilson.html Ali

Is there a way to disable 'dub test' for applications?

I have an dub config file specifying a targetType of 'executable'. There is only one file, the file containing main(), and no unit tests. When I run 'dub test', dub builds and runs the executable. This is not really desirable. Is there a way to set up the dub configuration file to disable

Re: Anonymous structure

On Monday, 18 April 2016 at 03:57:26 UTC, Tofu Ninja wrote: x,y,and z seem to all be immutable and all have the UDA testUDA. But even odder, it seems that "struct" in there is doing absolutely nothing. The same thing can be done with Yeah, any attribute can be grouped with braces or colons

Re: Anonymous structure

On Monday, 18 April 2016 at 03:33:53 UTC, Adam D. Ruppe wrote: The struct inside union is the main pure-language use case I know of though. Actually curiously I found another potential use, applying attributes/UDAs to multiple members at once. enum testUDA; struct T{ @testUDA

Re: Anonymous structure

On Monday, 18 April 2016 at 03:33:53 UTC, Adam D. Ruppe wrote: The struct inside union is the main pure-language use case I know of though. I understand the reason for allowing it in a union, I just don't see the reason it was extended to all aggregates as it seems to do nothing.

Re: Anonymous structure

On Monday, 18 April 2016 at 02:42:15 UTC, Nicholas Wilson wrote: IIRC D doesn't allow anonymous structures. They are allowed only if they are inside another aggregate.

Re: Anonymous structure

On Monday, 18 April 2016 at 02:12:24 UTC, Tofu Ninja wrote: Just out of curiosity, what is the point of the following? struct a{ struct{ int x; int y; int z; } } The grouping matters when it is nested inside a union. Here's a

Re: Anonymous structure

On Monday, 18 April 2016 at 02:42:15 UTC, Nicholas Wilson wrote: On Monday, 18 April 2016 at 02:12:24 UTC, Tofu Ninja wrote: Just out of curiosity, what is the point of the following? struct a{ struct{ int x; int y; int z; } } As

Re: Anonymous structure

On Monday, 18 April 2016 at 02:12:24 UTC, Tofu Ninja wrote: Just out of curiosity, what is the point of the following? struct a{ struct{ int x; int y; int z; } } As far as I can tell, the anonymous structure does nothing. How is

Anonymous structure

Just out of curiosity, what is the point of the following? struct a{ struct{ int x; int y; int z; } } As far as I can tell, the anonymous structure does nothing. How is it different from struct a{ int x; int y;

Re: Any usable SIMD implementation?

On Monday, 18 April 2016 at 00:27:06 UTC, Joe Duarte wrote: On Tuesday, 5 April 2016 at 10:27:46 UTC, Walter Bright wrote: Besides, I think it's a poor design to customize the app for only one SIMD type. A better idea (I've repeated this ad nauseum over the years) is to have n modules, one for

Re: So what does (inout int = 0) do?

On Sunday, 17 April 2016 at 23:03:26 UTC, Adam D. Ruppe wrote: On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote: On 17.04.2016 18:44, Nick Treleaven wrote: I think @property is OK. No, it isn't: Seriously, @property is one of the biggest SNAFUs of the language. I think I'll

Re: Any usable SIMD implementation?

On Tuesday, 5 April 2016 at 10:27:46 UTC, Walter Bright wrote: Besides, I think it's a poor design to customize the app for only one SIMD type. A better idea (I've repeated this ad nauseum over the years) is to have n modules, one for each supported SIMD type. Compile and link all of them in,

Re: Better mixin error messages

On Sunday, 17 April 2016 at 23:10:38 UTC, Adam D. Ruppe wrote: On Sunday, 17 April 2016 at 22:08:55 UTC, Bauss wrote: Like I also said this does not apply to normal mixins but usually very big mixins composited of multiple mixins and template mixins. Why are your mixins so huge? But yeah, I

Re: Better mixin error messages

On Sunday, 17 April 2016 at 22:08:55 UTC, Bauss wrote: On Sunday, 17 April 2016 at 21:59:38 UTC, Timon Gehr wrote: On 17.04.2016 23:49, Bauss wrote: On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote: mixin(generate()); pragma(msg,generate()); That's not a solution to the problem,

Re: Better mixin error messages

On Sunday, 17 April 2016 at 22:08:55 UTC, Bauss wrote: Like I also said this does not apply to normal mixins but usually very big mixins composited of multiple mixins and template mixins. Why are your mixins so huge? But yeah, I would like to see it print the error line and a few

Re: Dealing with type information loss in Parameters Fields and Return type

On Sunday, 17 April 2016 at 13:56:38 UTC, Jonathan M Davis wrote: Perhaps, but be aware that Walter Bright thinks that size_t should stay as-is: http://forum.dlang.org/post/nevrsb$2ge1$1...@digitalmars.com Maybe some sort of general change to how aliases work would be acceptable and would

Re: So what does (inout int = 0) do?

On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote: On 17.04.2016 18:44, Nick Treleaven wrote: I think @property is OK. No, it isn't: Seriously, @property is one of the biggest SNAFUs of the language. I think I'll write an editorial about this stuff in TWID tonight. (I'm also

Re: Another issue with the website

On Sunday, 17 April 2016 at 09:43:09 UTC, Marc Schütz wrote: The "source" link at the bottom is broken, though. That's a ddoc misdesign that I'm in the process of correcting.

Re: Can std.conv.toImpl please be deprecated

On Sunday, 17 April 2016 at 05:04:46 UTC, H. S. Teoh wrote: I'm pretty sure that toImpl being public is an oversight. The name itself implies that it should be private. I seriously doubt any user code actually calls toImpl directly... shouldn't it be just a matter of marking it private

Re: Better mixin error messages

On Sunday, 17 April 2016 at 21:59:38 UTC, Timon Gehr wrote: On 17.04.2016 23:49, Bauss wrote: On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote: mixin(generate()); pragma(msg,generate()); That's not a solution to the problem, because you will be printing ALL mixins and not just

Re: Can std.conv.toImpl please be deprecated

On Sunday, 17 April 2016 at 11:00:33 UTC, Jonathan M Davis wrote: What do you propose that we do instead? We need all of the separate toImpl functions regardless of the name. Do you want to try and embed them all inside of std.conv.to with the name to? I expect that it's feasible, but it would

Re: Better mixin error messages

On 17.04.2016 23:49, Bauss wrote: On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote: mixin(generate()); pragma(msg,generate()); That's not a solution to the problem, because you will be printing ALL mixins and not just the ones causing compilation errors. Obviously you'll insert

Re: Better mixin error messages

On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote: mixin(generate()); pragma(msg,generate()); That's not a solution to the problem, because you will be printing ALL mixins and not just the ones causing compilation errors.

[Issue 15857] incorrect checkimports mismatch for overload sets

https://issues.dlang.org/show_bug.cgi?id=15857 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/082e1199c258e99f7867ca33509db9ae9a31f3ae Issue 15857 - incorrect checkimports mismatch for overload

[Issue 15937] New: DMD should only expand tilde at start of paths

https://issues.dlang.org/show_bug.cgi?id=15937 Issue ID: 15937 Summary: DMD should only expand tilde at start of paths Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Keywords: pull

Re: So what does (inout int = 0) do?

On 17.04.2016 18:44, Nick Treleaven wrote: I think @property is OK. No, it isn't: import std.stdio; struct S{ @property int delegate() foo(){ return ()=>3; } } void main(){ S s; writeln(s.foo()); // "int delegate()" }

Re: Better mixin error messages

On 17.04.2016 23:18, Bauss wrote: Can there please be implemented something to retrieve the generated mixins that causes compiler errors; like perhaps a flag you pass that will print all mixins with compiler errors? Sometimes when you create highly dynamic mixins it can be hard to identify

Better mixin error messages

Can there please be implemented something to retrieve the generated mixins that causes compiler errors; like perhaps a flag you pass that will print all mixins with compiler errors? Sometimes when you create highly dynamic mixins it can be hard to identify errors in them, because you might

Re: New deb packages on d-apt

Hello, On Wednesday, 6 April 2016 at 13:06:54 UTC, Jordi Sayol wrote: d-apt has three new deb packages for Dfix, Dfmt and Dscanner. $ sudo apt-get install dfix dfmt dscanner d-apt JFYI - pegged is ready fo packaging: https://github.com/PhilippeSigaud/Pegged

Specifying a minimum Phobos version in dub?

Is there a way to specify a minimum Phobos version in a dub package specification? --Jon

Re: DIP64: Attribute Cleanup

On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote: http://wiki.dlang.org/DIP64 Attributes in D have two problems: 1. There are too many of them and declarations are getting too verbose 2. New attributes use @ and the old ones do not. I've created a DIP to address these issues.

Re: Can std.conv.toImpl please be deprecated

On Sun, Apr 17, 2016 at 03:32:16AM -0700, Jonathan M Davis via Digitalmars-d wrote: > On Saturday, April 16, 2016 22:04:46 H. S. Teoh via Digitalmars-d wrote: > > On Fri, Apr 15, 2016 at 05:23:26PM +, Jack Stouffer via Digitalmars-d > wrote: > > > Before I opened a PR, I wanted to get some

Re: So what does (inout int = 0) do?

On 17.04.2016 19:39, QAston wrote: First @property + compiler switch, now @property + deprecated switch. When should I use property? For all the getters? Should I start with property or with member access? Does it even matter because of optional parens? Why do I even need to care about this?

Re: .opAssign disabled without @disable

On 17.04.2016 13:00, denizzzka wrote: So, my problem is solved. But nevertheless maybe here is a problem in the compiler too. I've reduced the test case and filed an issue: https://issues.dlang.org/show_bug.cgi?id=15936

[Issue 15936] New: misleading error message about @disable where there is none

https://issues.dlang.org/show_bug.cgi?id=15936 Issue ID: 15936 Summary: misleading error message about @disable where there is none Product: D Version: D2 Hardware: All OS: All Status: NEW

[Issue 15935] New: compiling dub with -fPIC triggers internal compiler error

https://issues.dlang.org/show_bug.cgi?id=15935 Issue ID: 15935 Summary: compiling dub with -fPIC triggers internal compiler error Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW

Re: So what does (inout int = 0) do?

On Sunday, 17 April 2016 at 16:44:50 UTC, Nick Treleaven wrote: The @safe troika is a good design (except @safe should be the default), the implementation is lacking though. Ideallists want to make @safe strict now, but break code sometimes even without basic workarounds for memory-safe code.

Re: Who wore it better?

On Friday, 15 April 2016 at 17:24:19 UTC, Andrei Alexandrescu wrote: inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted BTW, why is overlap undocumented - is ctfe support a good enough reason? https://github.com/dlang/phobos/blob/v2.071.0/std/array.d#L715 I've thought about

[Issue 15911] undefined __Unwind_GetIPInfo for x86_64

https://issues.dlang.org/show_bug.cgi?id=15911 --- Comment #3 from Martin Nowak --- (In reply to Zane Sterling from comment #1) > Since upgrading to DMD 2.071.0 I've had this issue with compiling any D > programs, including a hello world. > > On OSX 10.11.4. As a workaround you

Re: DIP64: Attribute Cleanup

On Sunday, 17 April 2016 at 12:05:03 UTC, Anonymous5 wrote: If attributes are well split into sub categories, we could justify that a sub category will have @ and another not (e.g protection attributes: not @, functions attributes: @). The list of attributes that's not classified is: +

Re: So what does (inout int = 0) do?

On Sunday, 17 April 2016 at 14:30:59 UTC, QAston wrote: You've got lucky with pure (modulo corner cases) and ctfe, much less lucky with @safe, @trusted, @system, inout, shared, scope, property. The @safe troika is a good design (except @safe should be the default), the implementation is

Re: 2k questions on SO

On Sunday, 17 April 2016 at 12:10:47 UTC, Daniel Kozak wrote: http://stackoverflow.com/tags/d/info Awww, no [ldc] tag!

[Issue 15629] [REG2.066.0] wrong code with '-O -inline' but correct with '-O'

https://issues.dlang.org/show_bug.cgi?id=15629 --- Comment #9 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/6b54b4bcf6dfaa343992f3524e1bf15ffca07da3 fix Issue 15629 - [REG2.066.0] wrong code with '-O -inline'

[Issue 15861] [REG 2.069] Wrong double-to-string conversion with -O

https://issues.dlang.org/show_bug.cgi?id=15861 --- Comment #8 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/241f18c260618fe9b7083d29d8d975391a8a2561 Merge pull request #5650 from WalterBright/fix15861

[Issue 15402] allow private access to package symbols

https://issues.dlang.org/show_bug.cgi?id=15402 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/c424690156a6f2b4f402415c45e780833f2f2df2 fix Issue 15402 - allow private access to package symbols

[Issue 15898] [REG2.069] Internal error: backend\cgcod.c 1651

https://issues.dlang.org/show_bug.cgi?id=15898 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/4f32b7f31453107ad2c12f3801c9e916a718efd0 fix Issue 15898 - [REG2.069] Internal error: backend\cgcod.c

[Issue 15857] incorrect checkimports mismatch for overload sets

https://issues.dlang.org/show_bug.cgi?id=15857 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #5 from

[Issue 15857] incorrect checkimports mismatch for overload sets

https://issues.dlang.org/show_bug.cgi?id=15857 Kenji Hara changed: What|Removed |Added Keywords||diagnostic --

A Recurring Question

I recently found myself wanting an algorithm to apply f(x) repeatedly, generating an infinite sequence, for a variety of reasons. One of those reasons is to generate ancestor directories. Typically when I desire such a thing, I find myself trying to find the existing algorithm which does this

[Issue 15934] Non-virtual super class member function call ignores 'this' type qualifier

https://issues.dlang.org/show_bug.cgi?id=15934 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from

[Issue 15934] New: Non-virtual super class member function call ignores 'this' type qualifier

https://issues.dlang.org/show_bug.cgi?id=15934 Issue ID: 15934 Summary: Non-virtual super class member function call ignores 'this' type qualifier Product: D Version: D2 Hardware: All OS: All

Re: We need a couple hundreds of these

Am Fri, 15 Apr 2016 12:08:37 -0400 schrieb Andrei Alexandrescu : > https://github.com/D-Programming-Language/phobos/pull/4200 -- Andrei Whenever I notice something like that in my code, it makes me smile with the reassuring thought that the right design choices

Re: So what does (inout int = 0) do?

On Friday, 15 April 2016 at 20:03:07 UTC, Andrei Alexandrescu wrote: We should really do away with the cowboy style of designing language, which sadly Walter and I have been guilty of too often in the past. The slow but sure accretion of complexity of inout is a textbook example of where that

Re: Any usable SIMD implementation?

Am Sat, 16 Apr 2016 21:46:08 -0700 schrieb Walter Bright : > On 4/16/2016 2:40 PM, Marco Leise wrote: > > Tell me again, what's more elgant ! > > If I wanted to write in assembler, I wouldn't write in a high level language, > especially a weird one like GNU

[Issue 15884] Assigning char[] to std.json.JSONValue creates array, not string

https://issues.dlang.org/show_bug.cgi?id=15884 github-bugzi...@puremagic.com changed: What|Removed |Added Status|REOPENED|RESOLVED

[Issue 15884] Assigning char[] to std.json.JSONValue creates array, not string

https://issues.dlang.org/show_bug.cgi?id=15884 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/1f1ed031a3215b3fa6585ccca189d68c1ad5b154 Fix issue 15884 Encode wstring/wchar[]/dstring/dchar[]

Re: Somehow give a warning when trying to assign a size_t/ptrdiff_t to int or uint

On Sunday, 17 April 2016 at 11:26:02 UTC, Walter Bright wrote: My experience is that over time one gets used to writing 32/64 bit portable code naturally, and the minor irritations don't happen anymore. D isn't a language that tries to hide the differences, and one should be aware of them.

Re: Dealing with type information loss in Parameters Fields and Return type

On Sunday, April 17, 2016 12:07:45 Nicholas Wilson via Digitalmars-d-learn wrote: > On Sunday, 17 April 2016 at 11:47:52 UTC, Jonathan M Davis wrote: > > On Sunday, April 17, 2016 11:00:15 Nicholas Wilson via > > > > Digitalmars-d-learn wrote: > >> On Sunday, 17 April 2016 at 10:48:08 UTC,

Re: stc.experimental.ndslice -> sci.ndslice

On 04/17/2016 09:10 AM, Ilya Yaroshenko wrote: > We plan to add a set of numeric packages and this would be real pain if > they would be one-by-one moved from experimental to stable std. So sci.* > should be considered as experimental during few years. > > >

Re: Accessing __FILE__ and __LINE__ of caller in combination with varargs?

On Saturday, 16 April 2016 at 12:37:46 UTC, Simen Kjaeraas wrote: On Saturday, 16 April 2016 at 00:03:59 UTC, Jonathan M Davis wrote: On Friday, April 15, 2016 20:52:42 WebFreak001 via Digitalmars-d-learn wrote: void assertf(string file = __FILE__, size_t line = __LINE__, Args...)(lazy bool

Re: Dealing with type information loss in Parameters Fields and Return type

On Sunday, 17 April 2016 at 10:27:10 UTC, Nicholas Wilson wrote: On Sunday, 17 April 2016 at 10:22:00 UTC, Anonymouse wrote: On Sunday, 17 April 2016 at 10:12:29 UTC, Nicholas Wilson wrote: So currently there is a loss of information when Parameters Fields and Return type. i.e. assuming 64

Re: Dealing with type information loss in Parameters Fields and Return type

On Sunday, 17 April 2016 at 11:47:52 UTC, Jonathan M Davis wrote: On Sunday, April 17, 2016 11:00:15 Nicholas Wilson via Digitalmars-d-learn wrote: On Sunday, 17 April 2016 at 10:48:08 UTC, Jonathan M Davis wrote: > [...] Sorry for the confusion, I didn't. getting the string "size_t" as the

Re: DIP64: Attribute Cleanup

On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote: http://wiki.dlang.org/DIP64 Attributes in D have two problems: 1. There are too many of them and declarations are getting too verbose 2. New attributes use @ and the old ones do not. I've created a DIP to address these issues.

Re: Dealing with type information loss in Parameters Fields and Return type

On Sunday, April 17, 2016 11:00:15 Nicholas Wilson via Digitalmars-d-learn wrote: > On Sunday, 17 April 2016 at 10:48:08 UTC, Jonathan M Davis wrote: > > On Sunday, April 17, 2016 10:12:29 Nicholas Wilson via > > > > Digitalmars-d-learn wrote: > >> [...] > > > > I'm actually surprised that you

Re: Somehow give a warning when trying to assign a size_t/ptrdiff_t to int or uint

On 4/17/2016 2:29 AM, WebFreak001 wrote: It's annoying to fix all these `int index = str.indexOf("something")` to size_t/ptrdiff_t because you started writing the code thinking that indexOf returns an integer even though it returns a ptrdiff_t. When porting code from 32bit to 64bit you need to

Using D in Debian to build AppStream metadata.

Hello, Just read this post from Matthias Klumpp (http://blog.tenstral.net/2016/04/introducing-appstream-generator.html) in planet.debian.net where he talks about replacing the current appstream metadata generator written in python (dep11-generator). He talks about considering Go, Rust and D

Re: Dealing with type information loss in Parameters Fields and Return type

On Sunday, 17 April 2016 at 10:48:08 UTC, Jonathan M Davis wrote: On Sunday, April 17, 2016 10:12:29 Nicholas Wilson via Digitalmars-d-learn wrote: [...] I'm actually surprised that you got the compiler to give you size_t in any form. size_t is simply an alias to either ulong (on 64-bit

Re: .opAssign disabled without @disable

As Alex Parrill says, on problem was in const member. But this is one of the problems, and after fix here still was an error. But alphaglosined found another problem! For some unknown reason here it is need to specify an empty postblit constructor. Full patch:

Re: Can std.conv.toImpl please be deprecated

On Friday, April 15, 2016 17:23:26 Jack Stouffer via Digitalmars-d wrote: > Before I opened a PR, I wanted to get some second opinions. > > There is no reason IMO that the various overloads of toImpl > should be public. Having the internal functionality of a parent > function, in this case to, be

Re: Somehow give a warning when trying to assign a size_t/ptrdiff_t to int or uint

On Sunday, April 17, 2016 09:51:07 WebFreak001 via Digitalmars-d wrote: > On Sunday, 17 April 2016 at 09:38:33 UTC, Temtaime wrote: > > On Sunday, 17 April 2016 at 09:29:33 UTC, WebFreak001 wrote: > >> It's annoying to fix all these `int index = > >> str.indexOf("something")` to size_t/ptrdiff_t

Re: Dealing with type information loss in Parameters Fields and Return type

On Sunday, April 17, 2016 10:12:29 Nicholas Wilson via Digitalmars-d-learn wrote: > So currently there is a loss of information when Parameters > Fields and Return type. > i.e. assuming 64 bits > size_t foo(ptrdiff_t) {}; > > writeln(ReturnType!foo); // prints ulong > > Is there any way to get

Re: Can std.conv.toImpl please be deprecated

On Saturday, April 16, 2016 22:04:46 H. S. Teoh via Digitalmars-d wrote: > On Fri, Apr 15, 2016 at 05:23:26PM +, Jack Stouffer via Digitalmars-d wrote: > > Before I opened a PR, I wanted to get some second opinions. > > > > There is no reason IMO that the various overloads of toImpl should be

Re: Dealing with type information loss in Parameters Fields and Return type

On Sunday, 17 April 2016 at 10:22:00 UTC, Anonymouse wrote: On Sunday, 17 April 2016 at 10:12:29 UTC, Nicholas Wilson wrote: So currently there is a loss of information when Parameters Fields and Return type. i.e. assuming 64 bits size_t foo(ptrdiff_t) {}; writeln(ReturnType!foo); // prints

Re: Dealing with type information loss in Parameters Fields and Return type

On Sunday, 17 April 2016 at 10:12:29 UTC, Nicholas Wilson wrote: So currently there is a loss of information when Parameters Fields and Return type. i.e. assuming 64 bits size_t foo(ptrdiff_t) {}; writeln(ReturnType!foo); // prints ulong Is there any way to get the types as (tuples of)

Dealing with type information loss in Parameters Fields and Return type

So currently there is a loss of information when Parameters Fields and Return type. i.e. assuming 64 bits size_t foo(ptrdiff_t) {}; writeln(ReturnType!foo); // prints ulong Is there any way to get the types as (tuples of) strings of the the types as they are in the source file? auto foos =

Re: stc.experimental.ndslice -> sci.ndslice

On Sunday, 17 April 2016 at 09:44:30 UTC, Ilya Yaroshenko wrote: This would be a real pain for a user if he supports few compiler versions. This approach is wrong because you assume there won't be changes to how module works while in experimental and during transition from experimental to

Re: stc.experimental.ndslice -> sci.ndslice

On 17.04.2016 11:44, Ilya Yaroshenko wrote: This would be a real pain for a user if he supports few compiler versions. static if(__VERSION__ < 2072) { import std.experimental.sci.ndslice; } else { import std.sci.ndslice; } [...] Breakage is what you sign up for when using

Re: Somehow give a warning when trying to assign a size_t/ptrdiff_t to int or uint

On Sunday, 17 April 2016 at 09:38:33 UTC, Temtaime wrote: On Sunday, 17 April 2016 at 09:29:33 UTC, WebFreak001 wrote: It's annoying to fix all these `int index = str.indexOf("something")` to size_t/ptrdiff_t because you started writing the code thinking that indexOf returns an integer even

Re: stc.experimental.ndslice -> sci.ndslice

On Sunday, 17 April 2016 at 09:32:25 UTC, QAston wrote: On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko wrote: Just with std.sci.* without `experimental`. Otherwise this would be the same problem. What's wrong with std.experimental.sci.*? experimental is where experimental

Re: Another issue with the website

On Sunday, 17 April 2016 at 02:03:06 UTC, Adam D. Ruppe wrote: BTW, my superior doc site handles it this way: http://dpldocs.info/experimental-docs/std.experimental.allocator.html It marries the package.d contents along with the other concept of package as a collection of submodules. The

Re: Somehow give a warning when trying to assign a size_t/ptrdiff_t to int or uint

On Sunday, 17 April 2016 at 09:29:33 UTC, WebFreak001 wrote: It's annoying to fix all these `int index = str.indexOf("something")` to size_t/ptrdiff_t because you started writing the code thinking that indexOf returns an integer even though it returns a ptrdiff_t. When porting code from 32bit

Re: Can std.conv.toImpl please be deprecated

On Sunday, 17 April 2016 at 09:22:21 UTC, WebFreak001 wrote: you need to use toImpl if you want to convert a number to/from a specific base! I use that a lot when converting hexadecimal values No, the documentation just gives that impression. This works: void main(string[] args) {

Re: Which application is much suited and which is not.

On Saturday, 16 April 2016 at 18:13:57 UTC, Bauss wrote: On Saturday, 16 April 2016 at 14:08:05 UTC, newB wrote: Let's say you have decided to use D programming language. For what kind of applications would you choose D programming language and For what kind of applications you won't

Re: stc.experimental.ndslice -> sci.ndslice

On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko wrote: Just with std.sci.* without `experimental`. Otherwise this would be the same problem. What's wrong with std.experimental.sci.*? experimental is where experimental modules/packages should go.

Somehow give a warning when trying to assign a size_t/ptrdiff_t to int or uint

It's annoying to fix all these `int index = str.indexOf("something")` to size_t/ptrdiff_t because you started writing the code thinking that indexOf returns an integer even though it returns a ptrdiff_t. When porting code from 32bit to 64bit you need to fix all these lines which can quickly

Re: Can std.conv.toImpl please be deprecated

On Friday, 15 April 2016 at 17:23:26 UTC, Jack Stouffer wrote: Before I opened a PR, I wanted to get some second opinions. There is no reason IMO that the various overloads of toImpl should be public. Having the internal functionality of a parent function, in this case to, be exposed like

Re: stc.experimental.ndslice -> sci.ndslice

On Sunday, 17 April 2016 at 08:49:53 UTC, Seb wrote: On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko wrote: On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev I don't understand, what's wrong with std.sci or etc.sci? I am ok with std.sci for example. I just want to

Re: Can std.conv.toImpl please be deprecated

On Sunday, 17 April 2016 at 05:04:46 UTC, H. S. Teoh wrote: On Fri, Apr 15, 2016 at 05:23:26PM +, Jack Stouffer via Digitalmars-d wrote: [...] I'm pretty sure that toImpl being public is an oversight. The name itself implies that it should be private. I seriously doubt any user code

Re: stc.experimental.ndslice -> sci.ndslice

On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko wrote: On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev wrote: On Sunday, 17 April 2016 at 07:25:55 UTC, Ilya Yaroshenko wrote: sci name was reserved for future use: http://code.dlang.org/packages/sci What does a Dub

Re: .opAssign disabled without @disable

On Sunday, 17 April 2016 at 06:42:39 UTC, denizzzka wrote: Tried to build small test app - is not reproduced. Also tried to reduce source: https://github.com/denizzzka/r-tree/tree/314f7f1cc1b6387915dc56dcb2d3ccbc63e19275/source In this source line 199 causes this error

Re: stc.experimental.ndslice -> sci.ndslice

On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev wrote: On Sunday, 17 April 2016 at 07:25:55 UTC, Ilya Yaroshenko wrote: sci name was reserved for future use: http://code.dlang.org/packages/sci What does a Dub package have to do with D module system packages? The goal is to

Re: stc.experimental.ndslice -> sci.ndslice

On Sunday, 17 April 2016 at 07:25:55 UTC, Ilya Yaroshenko wrote: sci name was reserved for future use: http://code.dlang.org/packages/sci What does a Dub package have to do with D module system packages? The goal is to include only good consistent basic functionality for

Re: stc.experimental.ndslice -> sci.ndslice

On Sunday, 17 April 2016 at 07:11:17 UTC, Vladimir Panteleev wrote: On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote: We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be

Re: stc.experimental.ndslice -> sci.ndslice

On Sunday, 17 April 2016 at 07:02:25 UTC, Jack Stouffer wrote: On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote: We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered

Re: stc.experimental.ndslice -> sci.ndslice

On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote: We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.

Re: stc.experimental.ndslice -> sci.ndslice

On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote: We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.

Re: .opAssign disabled without @disable

Tried to build small test app - is not reproduced.

  1   2   >