Re: Get fils at compile-time

On 15/12/2016 8:11 PM, Bauss wrote: On Thursday, 15 December 2016 at 02:58:11 UTC, rikki cattermole wrote: I did a lot of work in this area. There are two solutions: 1) Use a package file and public import all modules via it. From this do some form of 'registration' in a module constructor.

Re: Compiling to shared library with static dependencies

On Wednesday, 14 December 2016 at 12:33:04 UTC, Tanel L wrote: Any ideas what to do or how to proceed? Thanks a bunch! This kind of questions is better adressed to the "Learn" forum.

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[about leaving the syntax as it is, only extend the import to include the previous (declaration) line] On Wednesday, 14 December 2016 at 21:21:39 UTC, Jonathan M Davis wrote: It also doesn't work with function prototypes. With the proposed syntax, you can do int foo(SysTime st)

Re: All function attributes possible with "@"?

On Thursday, 15 December 2016 at 03:56:56 UTC, Jonathan M Davis wrote: How on earth is that preferable? Sorry, forgot to actually answer your question. It is preferable since it is implied by a simple rule (function attributes go with @) rather than rote learning of effectively random

Re: Get fils at compile-time

On Thursday, 15 December 2016 at 02:58:11 UTC, rikki cattermole wrote: I did a lot of work in this area. There are two solutions: 1) Use a package file and public import all modules via it. From this do some form of 'registration' in a module constructor. Using __traits(allMembers, retrieve

Re: All function attributes possible with "@"?

On Thursday, 15 December 2016 at 03:56:56 UTC, Jonathan M Davis wrote: This does _nothing_ except maybe improve your ability to have aesthetically pleasing code if you think that slapping @ on all of the attributes is aesthetically pleasing (and a number of folks think that the @s are

Re: All function attributes possible with "@"?

On Wednesday, 14 December 2016 at 21:34:20 UTC, ketmar wrote: the only way for D to win (as i see it) is to deliver a better language. and that means dropping support for old code from time to time, not to stick with bad design forever. also, tools like dfix can be made to "upgrade" code.

Re: CTFE Status

On Tuesday, 13 December 2016 at 07:21:07 UTC, Stefan Koch wrote: Hi Guys, I just fixed the LLVM-Backend a little. It's about 4000 times slower to start up then the interpreter. And has 1000 microseconds overhead per evaluation. If you don't want to run a raytracer at compiletime I doubt that

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Thursday, 15 December 2016 at 03:26:24 UTC, Meta wrote: On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei What's the main goal with this proposal? Is it to introduce DCDs into the language or is it to

Re: Milestone - DMD front end is now 100% D!

On Thursday, 15 December 2016 at 05:03:20 UTC, Walter Bright wrote: On 12/14/2016 7:21 PM, Joakim wrote: How far do you plan to go in bringing D idioms to the compiler itself? A simple grep shows 3 C-style `for` loops in the frontend for every D `foreach`. Do you plan on using ranges and

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/16 4:38 PM, Timon Gehr wrote: On 15.12.2016 00:17, Andrej Mitrovic wrote: ubyte[] readSomeBytes ( ) { return read(1024); } It's a non-trivial exercise for the reader to understand where the `read` symbol is coming from. pragma(msg,fullyQualifiedName!read); Or, for the

Re: Milestone - DMD front end is now 100% D!

On 12/14/2016 7:21 PM, Joakim wrote: How far do you plan to go in bringing D idioms to the compiler itself? A simple grep shows 3 C-style `for` loops in the frontend for every D `foreach`. Do you plan on using ranges and algorithms, which likely means relying on Phobos at some point? Any

Re: Happy December 13th!

On Tuesday, 13 December 2016 at 13:57:33 UTC, Walter Bright wrote: On 12/13/2016 2:48 AM, Walter Bright wrote: What a great day to be alive! Just feeling really blessed today, and hope you all are too. This is a fake message. - the real Walter Well, it did seem like a rather odd post,

Re: All function attributes possible with "@"?

On Thursday, 15 December 2016 at 00:08:12 UTC, 01010100b wrote: On Wednesday, 14 December 2016 at 20:41:57 UTC, Jonathan M Davis wrote: Actually slapping @ on all keywords would remove the inconsistency altogether, even if that isn't necessarily what I favour. Keywords which are also function

Re: Simplest way to build a DMD compatible C lib, and how to link using DUB.

On Wednesday, 14 December 2016 at 23:08:30 UTC, hardreset wrote: I built Freetype with MSVC13 and tried to link it but DMD didnt like the format, so what should compiler (free) should I use for building DMD compatible static libs? The MS linker produces COFF format. By default, DMD uses the

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei What's the main goal with this proposal? Is it to introduce DCDs into the language or is it to clean up some warts of the local import pattern, i.e.: int

Re: Milestone - DMD front end is now 100% D!

On Thursday, 15 December 2016 at 01:04:54 UTC, Walter Bright wrote: The last one: https://github.com/dlang/dmd/pull/6310 Great! I see you've started moving the backend to D too, about 5% done so far. How far do you plan to go in bringing D idioms to the compiler itself? A simple grep

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 19:39:55 UTC, Andrei Alexandrescu wrote: On 12/14/2016 02:04 PM, Meta wrote: On Wednesday, 14 December 2016 at 17:32:10 UTC, H. S. Teoh wrote: What about: /* Showing full declaration just for context */ bool myFunc(R1, R2)(R1 r1, R2 r2) import {

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 15/12/2016 3:16 AM, Andrei Alexandrescu wrote: On 12/14/16 6:06 AM, rikki cattermole wrote: On 14/12/2016 11:33 AM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei Others have brought up similar syntax to this: import(my.mod).Type!argsT(7)

Re: Get fils at compile-time

I did a lot of work in this area. There are two solutions: 1) Use a package file and public import all modules via it. From this do some form of 'registration' in a module constructor. Using __traits(allMembers, retrieve the imports and with that the other modules. 2) Before compilation create

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Thursday, 15 December 2016 at 01:59:33 UTC, Timothee Cour wrote: how about this: variant 1 // currently legal D; just need to attach semantics ``` // applies to all below @deps!({import std.stdio; pragma(lib, "curl"); }): // applies to 1 below @deps!({import std.range}) void

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/2016 09:21 PM, Seb wrote: What is the use case for using "grep" to find all imports? The main idea here is to use "import" for importing things. -- Andrei

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 20:16:29 UTC, Andrei Alexandrescu wrote: On 12/14/2016 03:13 PM, bitwise wrote: I think the DIP indicated you may have considered this, but why not just remove the requirement of 'static import ..' for using fully qualified names? struct Buffered(Range) if

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

how about this: variant 1 // currently legal D; just need to attach semantics ``` // applies to all below @deps!({import std.stdio; pragma(lib, "curl"); }): // applies to 1 below @deps!({import std.range}) void fun(T)(isInputRange!T){} // depends on both deps void fun2(File file){} // depends

Re: Milestone - DMD front end is now 100% D!

ACHIEVEMENT UNLOCKED!

Milestone - DMD front end is now 100% D!

The last one: https://github.com/dlang/dmd/pull/6310

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Thursday, 15 December 2016 at 00:29:17 UTC, Chris M wrote: For the "with" keyword, why is the import statement kept? Seems unnecessary to keep it. void process(File input) import std.stdio; struct Buffered(Range) if (isInputRange!Range) with (std.range) { ... } to not block future

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/16 6:11 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Dec 14, 2016 at 04:08:56PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: On 12/14/2016 03:33 PM, H. S. Teoh via Digitalmars-d wrote: That's easy to fix: import { a : b, c; d: e, f; } The cost being adding new

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Thursday, 15 December 2016 at 00:44:02 UTC, Andrej Mitrovic wrote: On Wednesday, 14 December 2016 at 23:38:19 UTC, Timon Gehr wrote: On 15.12.2016 00:17, Andrej Mitrovic wrote: ubyte[] readSomeBytes ( ) { return read(1024); } It's a non-trivial exercise for the reader to understand

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 23:38:19 UTC, Timon Gehr wrote: On 15.12.2016 00:17, Andrej Mitrovic wrote: ubyte[] readSomeBytes ( ) { return read(1024); } It's a non-trivial exercise for the reader to understand where the `read` symbol is coming from.

Re: DRY version of `static if(__traits(compiles, expr)) fun(expr)`

On Wednesday, 14 December 2016 at 22:06:35 UTC, Ali Çehreli wrote: On 12/14/2016 09:25 AM, Basile B. wrote: > On Tuesday, 13 December 2016 at 23:37:59 UTC, Timon Gehr wrote: >> I usually do >> >> enum code = q{expr}; >> static if(__traits(compiles,mixin(code))) >> fun(mixin(code)); > >

Re: Dynamically Loading a D DLL From a D Program

On Wednesday, 14 December 2016 at 21:38:27 UTC, Benjiro wrote: Silly question: In this post about static / dynamic loading, i noticed that it uses the dlopen/dlclose, while there is a core.runtime for handling the loading. http://dlang.org/dll-linux.html#dso9 Dynamically Loading a D DLL From

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 22:55:26 UTC, Andrei Alexandrescu wrote: Made a pass through the document integrating a lot of feedback and fleshing the proposal better: https://github.com/andralex/DIPs/blob/155ff59984b26749af7830aeb172d3af2dae8cd7/DIPs/DIP1005.md

Re: Simplest way to build a DMD compatible C lib, and how to link using DUB.

On Wednesday, 14 December 2016 at 23:08:30 UTC, hardreset wrote: I built Freetype with MSVC13 and tried to link it but DMD didnt like the format, so what should compiler (free) should I use for building DMD compatible static libs? Once I've build the lib, made a di file, where do I put these

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/16 6:46 PM, arturg wrote: On Wednesday, 14 December 2016 at 22:56:54 UTC, Andrei Alexandrescu wrote: The acceptability of the proposal decays exponentially with its deviation from existing import syntax. -- Andrei sorry, i missed the import keyword :/ T1 fun(T1, T2)(T1 t1, T2 t2)

Re: All function attributes possible with "@"?

On Wednesday, 14 December 2016 at 20:41:57 UTC, Jonathan M Davis wrote: Because it's adding yet another inconsistency in the places that don't involve function attributes. After all, static and cost both get used in contexts where keywords such as auto and enum get used (neither of which are

[Issue 16960] implicit function return breaks chaining of exceptions

https://issues.dlang.org/show_bug.cgi?id=16960 Ali Cehreli changed: What|Removed |Added Summary|implicit function return|implicit function return

[Issue 16960] implicit function return breaks chaining of exceptions thrown in scope(exit)

https://issues.dlang.org/show_bug.cgi?id=16960 --- Comment #2 from Ali Cehreli --- Thanks opened issue 16972 as an enhancement. Perhaps the compiler can warn about the obvious throw there. --

[Issue 16972] New: Issue diagnostic for throwing from a scope(exit) block

https://issues.dlang.org/show_bug.cgi?id=16972 Issue ID: 16972 Summary: Issue diagnostic for throwing from a scope(exit) block Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity:

[Issue 16972] Issue diagnostic for throwing from a scope(exit) block

https://issues.dlang.org/show_bug.cgi?id=16972 Ali Cehreli changed: What|Removed |Added Priority|P1 |P3 --

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 22:56:54 UTC, Andrei Alexandrescu wrote: The acceptability of the proposal decays exponentially with its deviation from existing import syntax. -- Andrei sorry, i missed the import keyword :/ T1 fun(T1, T2)(T1 t1, T2 t2) import { version(A) {

[Issue 16971] Misleading error messages "break is not inside scope(exit) bodies" "continue is not inside scope(exit) bodies"

https://issues.dlang.org/show_bug.cgi?id=16971 Ali Cehreli changed: What|Removed |Added Priority|P1 |P5 --

[Issue 16971] New: Misleading error messages "break is not inside scope(exit) bodies" "continue is not inside scope(exit) bodies"

https://issues.dlang.org/show_bug.cgi?id=16971 Issue ID: 16971 Summary: Misleading error messages "break is not inside scope(exit) bodies" "continue is not inside scope(exit) bodies" Product: D Version: D2

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 15.12.2016 00:17, Andrej Mitrovic wrote: ubyte[] readSomeBytes ( ) { return read(1024); } It's a non-trivial exercise for the reader to understand where the `read` symbol is coming from. pragma(msg,fullyQualifiedName!read);

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wed, Dec 14, 2016 at 04:08:56PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 12/14/2016 03:33 PM, H. S. Teoh via Digitalmars-d wrote: > > That's easy to fix: > > > > import { a : b, c; d: e, f; } > > The cost being adding new syntax. -- Andrei Aren't we already adding new

Re: All function attributes possible with "@"?

On Wednesday, 14 December 2016 at 21:44:40 UTC, David Gileadi wrote: I've noticed that recent languages like Go and Swift are trying to have both by bundling a code fixer with new versions of their language. An automated code fixer in this case would be easy. Before looking up on the wiki

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 22:55:26 UTC, Andrei Alexandrescu wrote: Made a pass through the document integrating a lot of feedback and fleshing the proposal better: https://github.com/andralex/DIPs/blob/155ff59984b26749af7830aeb172d3af2dae8cd7/DIPs/DIP1005.md

Simplest way to build a DMD compatible C lib, and how to link using DUB.

I built Freetype with MSVC13 and tried to link it but DMD didnt like the format, so what should compiler (free) should I use for building DMD compatible static libs? Once I've build the lib, made a di file, where do I put these things in the dub directory structure? thanks,

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/2016 04:47 PM, ArturG wrote: On Wednesday, 14 December 2016 at 19:39:55 UTC, Andrei Alexandrescu wrote: On 12/14/2016 02:04 PM, Meta wrote: On Wednesday, 14 December 2016 at 17:32:10 UTC, H. S. Teoh wrote: What about: /* Showing full declaration just for context */ bool

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

Made a pass through the document integrating a lot of feedback and fleshing the proposal better: https://github.com/andralex/DIPs/blob/155ff59984b26749af7830aeb172d3af2dae8cd7/DIPs/DIP1005.md https://github.com/dlang/DIPs/pull/51/files Andrei

Re: Compiling to shared library with static dependencies

On Wednesday, 14 December 2016 at 22:17:25 UTC, Tanel L wrote: First of all thanks Johan for urging me to compile it with only with that flag. It worked! Previously I tried to compile it with only BUILD_SHARED or both - and that failed. But I got it working. Thanks! More details below.

Re: Compiling to shared library with static dependencies

First of all thanks Johan for urging me to compile it with only with that flag. It worked! Previously I tried to compile it with only BUILD_SHARED or both - and that failed. But I got it working. Thanks! More details below. On Wednesday, 14 December 2016 at 21:41:53 UTC, Relja Ljubobratovic

Re: DRY version of `static if(__traits(compiles, expr)) fun(expr)`

On 12/14/2016 09:25 AM, Basile B. wrote: > On Tuesday, 13 December 2016 at 23:37:59 UTC, Timon Gehr wrote: >> I usually do >> >> enum code = q{expr}; >> static if(__traits(compiles,mixin(code))) >> fun(mixin(code)); > > Strangely if i put this in a templated enum that doesn't work. > If

Re: All function attributes possible with "@"?

On Wednesday, 14 December 2016 at 21:02:09 UTC, Jonathan M Davis wrote: On Wednesday, 14 December 2016 at 12:00:04 UTC, ketmar wrote: [...] If we keep making breaking changes, we will never have a significant user base - especially if the changes are stylistic rather than providing real,

Re: All function attributes possible with "@"?

On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis wrote: On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote: So why not let all function attributes which are keywords also be allowed to be used with a "@" prefixed? Also, would you even allow @ on stuff like static

[Issue 16960] implicit function return breaks chaining of exceptions thrown in scope(exit)

https://issues.dlang.org/show_bug.cgi?id=16960 Mathias LANG changed: What|Removed |Added CC|

Re: Compiling to shared library with static dependencies

On Wednesday, 14 December 2016 at 21:41:53 UTC, Relja Ljubobratovic wrote: use just dcv:core with imageformats[1] http://code.dlang.org/packages/imageformats

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 19:39:55 UTC, Andrei Alexandrescu wrote: On 12/14/2016 02:04 PM, Meta wrote: On Wednesday, 14 December 2016 at 17:32:10 UTC, H. S. Teoh wrote: What about: /* Showing full declaration just for context */ bool myFunc(R1, R2)(R1 r1, R2 r2) import {

Re: All function attributes possible with "@"?

On 12/14/16 2:34 PM, ketmar wrote: On Wednesday, 14 December 2016 at 21:02:09 UTC, Jonathan M Davis wrote: If we keep making breaking changes, we will never have a significant user base so the core issue is a direction D developement should go: 1) have a good language, or 2) have big

Re: Compiling to shared library with static dependencies

On Wednesday, 14 December 2016 at 20:46:15 UTC, Tanel L wrote: Hi, thanks for the answer. I had tried disabling all imports, but now I created a clean new project to test this - it worked. Awesome. So LDC compile-link is ok, and also python runtime linking is good. After that I moved

Re: Shared object with Sqlite?

On Monday, 12 December 2016 at 15:39:47 UTC, Mike Parker wrote: On Monday, 12 December 2016 at 15:19:55 UTC, Benjiro wrot From my understanding, because the libdll has a shared tag, the libsqlite3.a needs to be linked as static and the rest needs to be dynamic. I found some examples using

Dynamically Loading a D DLL From a D Program

Silly question: In this post about static / dynamic loading, i noticed that it uses the dlopen/dlclose, while there is a core.runtime for handling the loading. http://dlang.org/dll-linux.html#dso9 Dynamically Loading a D DLL From a D Program void* lh = dlopen("libdll.so", RTLD_LAZY); //

Re: All function attributes possible with "@"?

On Wednesday, 14 December 2016 at 21:02:09 UTC, Jonathan M Davis wrote: If we keep making breaking changes, we will never have a significant user base so the core issue is a direction D developement should go: 1) have a good language, or 2) have big userbase. it looks like those goals are in

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 17:28:57 UTC, Andrei Alexandrescu wrote: On 12/14/2016 12:07 PM, David Gileadi wrote: The above rule doesn't cover non-template function declarations like the `process` example in the DIP, however. Are they an important enough use case to justify new syntax?

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 14:11:47 UTC, Andrei Alexandrescu wrote: * I predict 90% of the time there will be one import per declaration, which takes it down to: with (import std.range) void foo(T) if (isInputRange!T) {} which underlines the redundancy of the "with". Honestly, while

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/2016 03:33 PM, H. S. Teoh via Digitalmars-d wrote: That's easy to fix: import { a : b, c; d: e, f; } The cost being adding new syntax. -- Andrei

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 12:30:33 UTC, ketmar wrote: On Wednesday, 14 December 2016 at 12:15:20 UTC, Joseph Rushton Wakeling wrote: Yea, I think you put your finger on it: almost all of the stuff this feature could help achieve in Phobos could be just as well achieved by splitting

Re: All function attributes possible with "@"?

On Wednesday, 14 December 2016 at 12:00:04 UTC, ketmar wrote: On Wednesday, 14 December 2016 at 09:51:00 UTC, Joseph Rushton Wakeling wrote: On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis wrote: I say that when dealing with the built-in attributes, just treat @ like another

Re: Compiling to shared library with static dependencies

On Wednesday, 14 December 2016 at 12:33:04 UTC, Tanel L wrote: So I tried to compile LDC2 dynamically: cmake .. -DBUILD_SHARED=ON Have you tried `cmake .. -DBUILD_SHARED_LIBS=ON` ? -Johan

Re: Compiling to shared library with static dependencies

Hi, thanks for the answer. I had tried disabling all imports, but now I created a clean new project to test this - it worked. After that I moved the compiling and linking over to DUB, with dependencies: dependency "dcv" version="0.1.7" dependency "mir" version="0.22.0" targetPath "output"

Re: Get fils at compile-time

On Wednesday, 14 December 2016 at 20:47:23 UTC, bauss (wtf happend to my name took some old cached title LOL??) wrote: Is there a way to get all files in a folder at compile-time. To be more specific I want to import the content of all files within a specific folder during compile-time. I know

Get fils at compile-time

Is there a way to get all files in a folder at compile-time. To be more specific I want to import the content of all files within a specific folder during compile-time. I know how to do it with a specific file using `import("filename")`, but what if I wanted to do it at compile-time for all

Re: All function attributes possible with "@"?

On Wednesday, 14 December 2016 at 19:22:12 UTC, 01010100b wrote: On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis wrote: On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote: So why not let all function attributes which are keywords also be allowed to be used with a

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wed, Dec 14, 2016 at 02:30:29PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 12/14/2016 12:32 PM, H. S. Teoh via Digitalmars-d wrote: > > import { > > std.range : isInputRange, > > std.traits : isNum = isNumeric > > } > > This seems ambiguous. In >

Re: All function attributes possible with "@"?

On Wednesday, 14 December 2016 at 19:22:12 UTC, 01010100b wrote: On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis wrote: Also, would you even allow @ on stuff like static or const? Why not? Really? @pure @final @nogc func(); @final class G{} @@

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/2016 03:13 PM, bitwise wrote: On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei I think the DIP indicated you may have considered this, but why not just remove the requirement of 'static import ..'

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei I think the DIP indicated you may have considered this, but why not just remove the requirement of 'static import ..' for using fully qualified names?

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/13/2016 05:33 PM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files I just realized there is a ddoc consequence to this: ddoc could generate the import list and make that available to the generated documentation. I'll add that to the DIP. -- Andrei

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/2016 02:04 PM, Meta wrote: On Wednesday, 14 December 2016 at 17:32:10 UTC, H. S. Teoh wrote: What about: /* Showing full declaration just for context */ bool myFunc(R1, R2)(R1 r1, R2 r2) import { std.range : isInputRange, std.traits : isNum = isNumeric

Re: Compiling to shared library with static dependencies

On Wednesday, 14 December 2016 at 12:33:04 UTC, Tanel L wrote: Hello, Hi Tanel, I have just tried replicating the task you describe, and it worked flawlessly for me. I am very new to the D world - but serious in moving over to it after I have seen what a cool language it really is. I am

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/2016 02:22 PM, Timothee Cour via Digitalmars-d wrote: What about simply this: ``` module foo; { import std.stdio; void fun(File foo){} } { import sd.range; void foo(T) if(isInputRange!T){} } ``` Walter proposed this as well. We found two problems with it: (a) it is not clear

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/2016 12:32 PM, H. S. Teoh via Digitalmars-d wrote: import { std.range : isInputRange, std.traits : isNum = isNumeric } This seems ambiguous. In import { a : b, c.d } did you meant to import c.d from a, or a different module? Andrei

[Issue 7016] local import does not create -deps dependency

https://issues.dlang.org/show_bug.cgi?id=7016 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |ASSIGNED

[Issue 7016] local import does not create -deps dependency

https://issues.dlang.org/show_bug.cgi?id=7016 --- Comment #16 from Andrei Alexandrescu --- Thanks. Razvan will be on this. --

Re: All function attributes possible with "@"?

On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis wrote: On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote: So why not let all function attributes which are keywords also be allowed to be used with a "@" prefixed? Because it just creates yet another way to make one

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

What about simply this: ``` module foo; { import std.stdio; void fun(File foo){} } { import sd.range; void foo(T) if(isInputRange!T){} } ``` On Wed, Dec 14, 2016 at 9:50 AM, ketmar via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Wednesday, 14 December 2016 at 17:32:10 UTC, H.

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 17:32:10 UTC, H. S. Teoh wrote: What about: /* Showing full declaration just for context */ bool myFunc(R1, R2)(R1 r1, R2 r2) import { std.range : isInputRange, std.traits : isNum = isNumeric }

[Issue 7016] local import does not create -deps dependency

https://issues.dlang.org/show_bug.cgi?id=7016 Timothee Cour changed: What|Removed |Added CC|

[Issue 7016] local import does not create -deps dependency

https://issues.dlang.org/show_bug.cgi?id=7016 Vladimir Panteleev changed: What|Removed |Added Hardware|Other |All

[Issue 7016] local import does not create -deps dependency

https://issues.dlang.org/show_bug.cgi?id=7016 Mathias Lang changed: What|Removed |Added CC|

[Issue 16970] Fix deprecations and warnings when compiling Phobos

https://issues.dlang.org/show_bug.cgi?id=16970 Andrei Alexandrescu changed: What|Removed |Added CC||and...@erdani.com

[Issue 7016] local import does not create -deps dependency

https://issues.dlang.org/show_bug.cgi?id=7016 --- Comment #13 from Andrei Alexandrescu --- So is this on Windows only? Just confirming. --

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 17:32:10 UTC, H. S. Teoh wrote: What about: /* Showing full declaration just for context */ bool myFunc(R1, R2)(R1 r1, R2 r2) import { std.range : isInputRange, std.traits : isNum = isNumeric }

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 17:24:42 UTC, Andrej Mitrovic wrote: On Wednesday, 14 December 2016 at 17:09:44 UTC, ketmar wrote: bool equal(R1, R2) : std.range, std.traits if (isInputRange!R1 && isInputRange!R2 && isArray!R2) { ... } breaks possible selective import. if both modules

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wed, Dec 14, 2016 at 05:24:42PM +, Andrej Mitrovic via Digitalmars-d wrote: > On Wednesday, 14 December 2016 at 17:09:44 UTC, ketmar wrote: > > > bool equal(R1, R2) : std.range, std.traits > > > if (isInputRange!R1 && isInputRange!R2 && isArray!R2) > > > { ... } > > > > breaks possible

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/2016 12:28 PM, Anonymouse wrote: On Wednesday, 14 December 2016 at 17:24:29 UTC, Anonymouse wrote: The with keyword then? bool equal(R1, R2) with (std.range : isInputRange, isOutputRange) && (std.stdio : writeln) && (std.algorithm) if (isInputRange!R1 && isInputRange!R2) { ... } I

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/2016 12:24 PM, Anonymouse wrote: On Wednesday, 14 December 2016 at 17:09:44 UTC, ketmar wrote: On Wednesday, 14 December 2016 at 17:01:50 UTC, Andrej Mitrovic How about: bool equal(R1, R2) : std.range if (isInputRange!R1 && isInputRange!R2) { ... } It's nice and concise, and you

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/14/2016 12:07 PM, David Gileadi wrote: The above rule doesn't cover non-template function declarations like the `process` example in the DIP, however. Are they an important enough use case to justify new syntax? I suspect 90% of all uses will be straight definitions of template

Re: DRY version of `static if(__traits(compiles, expr)) fun(expr)`

On Tuesday, 13 December 2016 at 23:37:59 UTC, Timon Gehr wrote: On 14.12.2016 00:00, Timothee Cour via Digitalmars-d-learn wrote: what's the best (and DRY) way to achieve: ``` static if(__traits(compiles, expr)) fun(expr); ``` ie, without repeating the expression inside expr? eg: ```

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Wednesday, 14 December 2016 at 17:24:29 UTC, Anonymouse wrote: The with keyword then? bool equal(R1, R2) with (std.range : isInputRange, isOutputRange) && (std.stdio : writeln) && (std.algorithm) if (isInputRange!R1 && isInputRange!R2) { ... } I guess the & there don't make sense. Maybe

  1   2   >