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.
[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) import(st
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 histori
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 downright
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.
C
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 th
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 cle
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 IDE-addi
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, eve
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 a
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 d
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 {
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)
import
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 fun(T)(isInputR
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
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 (s
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
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 uses
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 sy
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
wh
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.
pragma(msg,fullyQualifiedName!
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
https://github.com/dlang/DI
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)
im
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 fu
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)
{ impor
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);
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 sy
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 why
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
https://github.com/dlang/DI
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 myFun
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
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.
Aweso
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 w
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, techn
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 or
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
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 {
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 userbase.
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 the
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 Gcc
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 c
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?
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 I
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
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 stuf
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 le
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
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"
t
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 "@"
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
>
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{}
@@
And,
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 ..' f
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?
stru
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
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
}
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 tr
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 that
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
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 p
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.
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
}
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
}
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 export
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 sel
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 gu
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 cou
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
functions
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 &&s there don't make sense. Maybe
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 exports some
symbol, we will need to selectively import and/or rename it.
N
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 could in theory also allow
multiple imports w
On Wednesday, 14 December 2016 at 17:01:50 UTC, Andrej Mitrovic
wrote:
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei
Alexandrescu wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Andrei
How about:
bool equal(R1, R2) : std.range
if (isInputRange!R1 && isInputRange!R2)
{ ..
On 12/14/16 9:27 AM, Andrei Alexandrescu wrote:
On 12/14/2016 11:02 AM, default0 wrote:
On Wednesday, 14 December 2016 at 14:21:55 UTC, Andrei Alexandrescu
wrote:
On 12/14/16 8:26 AM, Dominikus Dittes Scherkl wrote:
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu
wrote:
Dest
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu
wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Andrei
How about:
bool equal(R1, R2) : std.range
if (isInputRange!R1 && isInputRange!R2)
{ ... }
It's nice and concise, and you could in theory also allow
multiple
On 12/14/2016 11:02 AM, default0 wrote:
On Wednesday, 14 December 2016 at 14:21:55 UTC, Andrei Alexandrescu wrote:
On 12/14/16 8:26 AM, Dominikus Dittes Scherkl wrote:
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
On Wednesday, 14 December 2016 at 14:21:55 UTC, Andrei
Alexandrescu wrote:
On 12/14/16 8:26 AM, Dominikus Dittes Scherkl wrote:
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei
Alexandrescu wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Why not leave it as it is and only cha
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu
wrote:
Destroy.
FWIW, the reason why I don't use inline imports in my code:
http://d.puremagic.com/issues/show_bug.cgi?id=7016
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:
[...]
exactly the kind of logic that made c++.
[...]
This. This. This.
On Wednesday, 14 December 2016 at 14:19:43 UTC, Andrei
Alexandrescu wrote:
On 12/14/16 7:30 AM, ketmar wrote:
finally, some DIP that addresses something i really think
about almost
every day.
Additional motivating examples are welcome. -- Andrei
it happened that DIP itself has all the sampl
On 12/14/16 8:26 AM, Dominikus Dittes Scherkl wrote:
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Why not leave it as it is and only change the compiler to
perform inputs _within_ a function before evaluating the
On 12/14/16 7:30 AM, ketmar wrote:
finally, some DIP that addresses something i really think about almost
every day.
Additional motivating examples are welcome. -- Andrei
On 12/14/16 7:01 AM, Mathias Lang wrote:
Trouble is, there's no real difference between doing that, vs.
creating a standalone module containing `foo` and `bar` with `import
std.range;` as a top-level import.
That was my impression when reading this DIP. I'm very glad to see that
decoupling made
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)
import(Identifier).Identifier
It shouldn't be confused w
On 12/14/16 5:55 AM, pineapple wrote:
On Wednesday, 14 December 2016 at 01:53:44 UTC, Chris M. wrote:
How about using "imports" instead of "import"? Simple enough change,
and it still makes sense
bool equal(R1, R2)
imports (std.range)
if (isInputRange!R1 && isInputRange!R2)
{ ... }
On Tuesday
On 12/14/16 3:43 AM, Yuxuan Shui wrote:
@import("std.range"):
This seems to break the requirement that declaration-local imports
should offer the same amenities as regular imports. It would seem much
if we started putting all of the import syntax in strings. -- Andrei
On 12/14/16 3:17 AM, Dicebot wrote:
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Andrei
Proposed functionality does feel useful but syntax options mentioned in
the DIP all seem lacking to me. Most importantly,
On 12/14/16 2:17 AM, Jacob Carlborg wrote:
On 2016-12-14 03:23, Andrei Alexandrescu wrote:
On 12/13/16 9:22 PM, Hatem Oraby wrote:
with(import std.range)
bool equal(R1, R2) if (isInputRange!R1 && isInputRange!R2)
{ ... }
I considered this, then figured with is superfluous. -- Andrei
It co
On 12/14/16 12:00 AM, Suliman wrote:
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Imho such syntaxis construction make language harder to learn. D is
already pretty complex, but DIPs should simplify language, but
On 12/13/16 10:37 PM, Jon Degenhardt wrote:
I didn't see an example of the syntax when multiple imports are involved
(apologies if I missed it). Would be good to spell it out.
Thanks for the point and examples, will change the DIP accordingly. --
Andrei
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu
wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Andrei
How about something like Haskells "where" to allow any set of
pre-declaration just for one declaration:
with
{
import ...;
alias Result = ...;
}
Result func
On 2016-12-14 14:26, Dominikus Dittes Scherkl via Digitalmars-d wrote:
> On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>
> Why not leave it as it is and only change the compiler to
> perform inputs _within_ a f
I really like that solution. +1
14.12.2016 16:26, Dominikus Dittes Scherkl пишет:
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Why not leave it as it is and only change the compiler to
perform inputs _within_ a function before evaluating the de
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu
wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Why not leave it as it is and only change the compiler to
perform inputs _within_ a function before evaluating the
declaration, so that the symbols imported can be use
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 le
On 14/12/16 14:16, Idan Arye wrote:
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
Then why
Hello,
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 trying to incorporate D into our main product as an
externally loadable module.
Basically I have a minimal project:
./app.d
./helpers/image.d (mir and dcv libraries
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 stuff up better.
no, it can't. why should i remember that i have
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
Then why is your Gravatar account called "wal
On Wednesday, 14 December 2016 at 12:01:40 UTC, Mathias Lang
wrote:
That was my impression when reading this DIP. I'm very glad to
see that decoupling made its way up in the growing list of
things to do, my only concern is that this syntax sounds like a
workaround for giant modules.
Phobos is
On 14.12.2016 10:01, Joseph Rushton Wakeling wrote:
On Wednesday, 14 December 2016 at 07:17:57 UTC, Jacob Carlborg wrote:
On 2016-12-14 03:23, Andrei Alexandrescu wrote:
On 12/13/16 9:22 PM, Hatem Oraby wrote:
with(import std.range)
bool equal(R1, R2) if (isInputRange!R1 && isInputRange!R2)
1 - 100 of 115 matches
Mail list logo
