Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: On 2/14/2017 8:25 AM, Andrei Alexandrescu wrote: Range remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset) if (s != SwapStrategy.stable && isBidirectionalRange!Range &&

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 02/22/2017 06:53 AM, Atila Neves wrote: On Thursday, 16 February 2017 at 13:21:04 UTC, Andrei Alexandrescu wrote: On 2/16/17 7:11 AM, Atila Neves wrote: On Wednesday, 15 February 2017 at 17:10:26 UTC, Adam D. Ruppe wrote: On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Thursday, 16 February 2017 at 13:21:04 UTC, Andrei Alexandrescu wrote: On 2/16/17 7:11 AM, Atila Neves wrote: On Wednesday, 15 February 2017 at 17:10:26 UTC, Adam D. Ruppe wrote: On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote: Your documentation is an improvement but

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Sunday, 19 February 2017 at 01:53:58 UTC, Timothee Cour wrote: Doesn't add indentation: with (module_!"std.stdio, std.traits") void fun(T)(File input, T value) if (isIntegral!T); * what is the implementation of `module_` ? `from` defined earlier doesn't allow for multiple modules as in

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

> Doesn't add indentation: > > with (module_!"std.stdio, std.traits") > void fun(T)(File input, T value) > if (isIntegral!T); * what is the implementation of `module_` ? `from` defined earlier doesn't allow for multiple modules as in from!"std.stdio, std.traits"`. But let's assume it can be done

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Friday, 17 February 2017 at 04:09:14 UTC, timotheecour wrote: * with(module_!"std.foo") is useful for scoping imports to cover several declarations and being DRY; at the expense of adding indentation/nesting and less nice syntax Doesn't add indentation: with (module_!"std.stdio,

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 20:21:45 UTC, Nick Treleaven wrote: On Wednesday, 15 February 2017 at 20:09:46 UTC, Timothee Cour wrote: This thread completely diverged from the original post, which was propsing `::` instead of `from!`: ``` void fun(T)(std.stdio::File input, T value) if

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 19:39:52 UTC, Andrei Alexandrescu wrote: On 02/15/2017 06:20 AM, Daniel N wrote: On Wednesday, 15 February 2017 at 09:22:14 UTC, Daniel N wrote: template every(T...) { template satisfies(U...) { enum satisfies = true; } } (lunch-break =>

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2/16/17 7:11 AM, Atila Neves wrote: On Wednesday, 15 February 2017 at 17:10:26 UTC, Adam D. Ruppe wrote: On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote: Your documentation is an improvement but it doesn't help when reading the source code. Yeah, I think there's a few

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 17:10:26 UTC, Adam D. Ruppe wrote: On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote: Your documentation is an improvement but it doesn't help when reading the source code. Yeah, I think there's a few things we can do in the source too. We

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Thursday, 16 February 2017 at 07:48:37 UTC, Jacob Carlborg wrote: On 2017-02-16 01:40, John Colvin wrote: Slightly OT, but it is related so bear with me: Design by introspection is great and prevent having to make new names for every possible combo of features. Unfortunately, it doesn't

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Thursday, 16 February 2017 at 07:34:02 UTC, Jacob Carlborg wrote: On 2017-02-16 01:37, ZombineDev wrote: BTW, shouldn't we use `enum`, instead of `auto`, since everywhere else `enum` means guaranteed to be computed at compile-time whereas `auto` means the opposite? Far enough, since

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Thursday, 16 February 2017 at 00:40:19 UTC, John Colvin wrote: On Wednesday, 15 February 2017 at 19:39:52 UTC, Andrei Alexandrescu wrote: On 02/15/2017 06:20 AM, Daniel N wrote: On Wednesday, 15 February 2017 at 09:22:14 UTC, Daniel N wrote: template every(T...) { template

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2017-02-16 01:40, John Colvin wrote: Slightly OT, but it is related so bear with me: Design by introspection is great and prevent having to make new names for every possible combo of features. Unfortunately, it doesn't work so well for introspecting multiple types at once: normally you have

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2017-02-16 01:37, ZombineDev wrote: BTW, shouldn't we use `enum`, instead of `auto`, since everywhere else `enum` means guaranteed to be computed at compile-time whereas `auto` means the opposite? Far enough, since it's not possible to change the parameter inside the function anyway.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Thursday, 16 February 2017 at 00:37:00 UTC, ZombineDev wrote: On Thursday, 16 February 2017 at 00:08:12 UTC, Walter Bright wrote: On 2/15/2017 12:31 PM, Jonathan M Davis via Digitalmars-d wrote: It's one of those features that I was surprised when you couldn't do it. It was an oversight.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 19:39:52 UTC, Andrei Alexandrescu wrote: On 02/15/2017 06:20 AM, Daniel N wrote: On Wednesday, 15 February 2017 at 09:22:14 UTC, Daniel N wrote: template every(T...) { template satisfies(U...) { enum satisfies = true; } } (lunch-break =>

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Thursday, 16 February 2017 at 00:08:12 UTC, Walter Bright wrote: On 2/15/2017 12:31 PM, Jonathan M Davis via Digitalmars-d wrote: It's one of those features that I was surprised when you couldn't do it. It was an oversight. We just never thought of it. What do you think about

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2/15/2017 12:31 PM, Jonathan M Davis via Digitalmars-d wrote: It's one of those features that I was surprised when you couldn't do it. It was an oversight. We just never thought of it.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

Also, as mentioned in the std.algorithm.mutation.remove case, constraints in Phobos often confuse "requirements" with "specializations". Requirements should be user-facing constraints, while specializations are implementation details better handled with internal static if.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2/15/2017 1:24 PM, Jonathan M Davis via Digitalmars-d wrote: So, regardless of the exact terminology, we have a whole set of very similar but subtly different traits. And as it stands, they _will_ get screwed up unless someone is carefully looking at each to make sure that they actually use

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 02/15/2017 03:31 PM, Jonathan M Davis via Digitalmars-d wrote: On Wednesday, February 15, 2017 14:30:02 Andrei Alexandrescu via Digitalmars-d wrote: On 02/15/2017 02:22 PM, Jacob Carlborg wrote: On 2017-02-15 15:01, Andrei Alexandrescu wrote: That's nice, could you please submit as an

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wed, Feb 15, 2017 at 09:03:46PM +, Jack Stouffer via Digitalmars-d wrote: > On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright wrote: > > I'd like to take a step back and devise a consistent taxonomy of these > > things > > Ok > > > 1. auto decoding dynamic arrays > > Narrow

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2/15/2017 1:03 PM, Jack Stouffer wrote: On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright wrote: I'd like to take a step back and devise a consistent taxonomy of these things Ok 1. auto decoding dynamic arrays Narrow strings 2. not auto decoding arrays Wide strings 3.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, February 15, 2017 21:03:46 Jack Stouffer via Digitalmars-d wrote: > On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright > > wrote: > > I'd like to take a step back and devise a consistent taxonomy > > of these things > > Ok > > > 1. auto decoding dynamic arrays > > Narrow

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright wrote: I'd like to take a step back and devise a consistent taxonomy of these things Ok 1. auto decoding dynamic arrays Narrow strings 2. not auto decoding arrays Wide strings 3. static arrays Do these need to be called

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

Please fix your newsreader so it submits postings in text format, not html.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, February 15, 2017 12:54:02 Walter Bright via Digitalmars-d wrote: > On 2/15/2017 10:51 AM, Andrei Alexandrescu wrote: > > isStringLike. I wanted to add this for a while already. Please do! -- > > Andrei > What I've found messy and confusing with string overloads in Phobos is > there

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2/15/2017 10:51 AM, Andrei Alexandrescu wrote: isStringLike. I wanted to add this for a while already. Please do! -- Andrei What I've found messy and confusing with string overloads in Phobos is there are at least 6 kinds of strings: 1. auto decoding dynamic arrays 2. not auto decoding

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, February 15, 2017 14:30:02 Andrei Alexandrescu via Digitalmars-d wrote: > On 02/15/2017 02:22 PM, Jacob Carlborg wrote: > > On 2017-02-15 15:01, Andrei Alexandrescu wrote: > >> That's nice, could you please submit as an enhancement request on > >> bugzilla? > > > >

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 20:09:46 UTC, Timothee Cour wrote: This thread completely diverged from the original post, which was propsing `::` instead of `from!`: ``` void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T) {...} ``` instead of: ``` void

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 18:51:40 UTC, Andrei Alexandrescu wrote: On 02/15/2017 12:18 PM, Seb wrote: uint getAttributes(R)(R name) if (isInputRange!R && !isInfinite!R && isSomeChar!(ElementEncodingType!R) && !isConvertibleToString!R); Now as this same block is used > 30x in Phobos

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

This thread completely diverged from the original post, which was propsing `::` instead of `from!`: ``` void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T) {...} ``` instead of: ``` void fun(T)(Module!"std.stdio".File input, T value) if (Module!"std.traits".isIntegral!T)

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 02/15/2017 06:20 AM, Daniel N wrote: On Wednesday, 15 February 2017 at 09:22:14 UTC, Daniel N wrote: template every(T...) { template satisfies(U...) { enum satisfies = true; } } (lunch-break => time to hack D!) template every(T...) { template satisfies(U...) {

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 02/15/2017 02:22 PM, Jacob Carlborg wrote: On 2017-02-15 15:01, Andrei Alexandrescu wrote: That's nice, could you please submit as an enhancement request on bugzilla? https://issues.dlang.org/show_bug.cgi?id=17186 Thanks. I'll take it up to Walter for preapproval. -- Andrei

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2017-02-15 15:01, Andrei Alexandrescu wrote: That's nice, could you please submit as an enhancement request on bugzilla? https://issues.dlang.org/show_bug.cgi?id=17186 -- /Jacob Carlborg

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 02/15/2017 12:18 PM, Seb wrote: uint getAttributes(R)(R name) if (isInputRange!R && !isInfinite!R && isSomeChar!(ElementEncodingType!R) && !isConvertibleToString!R); Now as this same block is used > 30x in Phobos one could argue that it makes sense to use a convenience trait like:

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 17:18:15 UTC, Seb wrote: Now as this same block is used > 30x in Phobos That tells me you already have an empirical clear win! If you wrote exactly the same thing 30x inside the functions, you'd move it out to a new function too. if

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 16:20:30 UTC, Chris Wright wrote: The greatest annoyance is if I have to read through several files of phobos sources just to figure out why there's no matching overload for this function call that looks right to me. I really really REALLY REALLY wish the

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 17:10:26 UTC, Adam D. Ruppe wrote: On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote: Your documentation is an improvement but it doesn't help when reading the source code. Yeah, I think there's a few things we can do in the source too. We

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote: Your documentation is an improvement but it doesn't help when reading the source code. Yeah, I think there's a few things we can do in the source too. We should find the common combinations and abstract them out, like I

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wed, 15 Feb 2017 08:56:00 +0100, Jacob Carlborg wrote: > Your documentation is an improvement but it doesn't help when reading > the source code. For me, it almost entirely obviates reading the source code. I only need to read it if I'm trying to modify it, at which point I'm already

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wed, 15 Feb 2017 05:28:11 +, Adam D. Ruppe wrote: > On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: >> A further improvement in the documentation would be to add links to >> isBidirectionalRange and hasLvalueElements. > > Kneel before your god! We're not worthy!

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, February 15, 2017 14:35:40 Jack Stouffer via Digitalmars-d wrote: > On Wednesday, 15 February 2017 at 08:53:30 UTC, Jacob Carlborg > > wrote: > > "The static if feature recently proposed for C++ [1, 2] is > > fundamentally flawed, and its adoption would be a disaster for > > the

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 14:01:28 UTC, Andrei Alexandrescu wrote: It still has a cargo cult flavor because it introduces a new scope, which kinda misses the point of static if. That's an understatement. Having static if introduce a new scope makes static if useless. Creating a new

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 08:53:30 UTC, Jacob Carlborg wrote: "The static if feature recently proposed for C++ [1, 2] is fundamentally flawed, and its adoption would be a disaster for the language" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf I honestly feel bad

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 22:01:47 UTC, H. S. Teoh wrote: Thankfully, the docs for std.conv.to have been greatly improved since the last time I had to work with the code -- everything is now consolidated under a single template function std.conv.to, and the implementation details are

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2/15/17 3:53 AM, Jacob Carlborg wrote: I do see a possibility for a slightly improvement in a different area, in the example of "remove". If we look at the signature, without the constraints: Range remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset)

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: Range remove [...] But there's another issue here. remove() has other overloads: [...] Two constraints are common to all three, those are the only ones that actually need to be in the constraint. The others can go in the

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 16:25:17 UTC, Andrei Alexandrescu wrote: On 02/14/2017 10:49 AM, Jacob Carlborg wrote: On 2017-02-14 15:37, Andrei Alexandrescu wrote: How are they so, Example [1]. That signature spans 8 lines, it took me 10 seconds to find the actual function name.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 01:09:59 UTC, Chris Wright wrote: Because now I have to look up the definition of fooConstraint and then I have to look up the definition of each element within it. To be honest, I don't often look at function definitions for the template constraints, but

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 09:22:14 UTC, Daniel N wrote: template every(T...) { template satisfies(U...) { enum satisfies = true; } } (lunch-break => time to hack D!) template every(T...) { template satisfies(U...) { enum satisfies = {

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Wednesday, 15 February 2017 at 08:59:49 UTC, Jacob Carlborg wrote: On 2017-02-15 09:19, Walter Bright wrote: On 2/14/2017 9:28 PM, Adam D. Ruppe wrote: On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: A further improvement in the documentation would be to add links to

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2017-02-15 09:19, Walter Bright wrote: On 2/14/2017 9:28 PM, Adam D. Ruppe wrote: On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: A further improvement in the documentation would be to add links to isBidirectionalRange and hasLvalueElements. Kneel before your god!

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2017-02-14 17:25, Andrei Alexandrescu wrote: My recollection is past discussions got stalled because the approach is combinatorially bankrupt. How would one express the constraints of the functions above with simple named constraints? (Not rhetorical; please do provide an example if

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2017-02-14 17:25, Andrei Alexandrescu wrote: My recollection is past discussions got stalled because the approach is combinatorially bankrupt. How would one express the constraints of the functions above with simple named constraints? (Not rhetorical; please do provide an example if

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2/14/2017 9:28 PM, Adam D. Ruppe wrote: On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: A further improvement in the documentation would be to add links to isBidirectionalRange and hasLvalueElements. Kneel before your god!

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2017-02-15 06:28, Adam D. Ruppe wrote: Kneel before your god! http://dpldocs.info/experimental-docs/std.algorithm.mutation.remove.1.html Take a look at this insane automatic cross referencing: http://dpldocs.info/experimental-docs/std.range.chain.html My ref thing still isn't perfect,

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: A further improvement in the documentation would be to add links to isBidirectionalRange and hasLvalueElements. Kneel before your god! http://dpldocs.info/experimental-docs/std.algorithm.mutation.remove.1.html Take a look at

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tue, 14 Feb 2017 19:08:53 +, bachmeier wrote: > I am not familiar with all of the past discussion of this issue, but > something that I have wondered is why we can't do something like > > alias fooConstraint = (s != SwapStrategy.stable >&& isBidirectionalRange!Range &&

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tue, 14 Feb 2017 21:33:00 +, Lurker wrote: > On Tuesday, 14 February 2017 at 16:25:17 UTC, Andrei Alexandrescu wrote: >> Range remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...) >> (Range range, Offset offset) >> if (s != SwapStrategy.stable >> &&

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2/14/2017 2:01 PM, H. S. Teoh via Digitalmars-d wrote: This is a good idea. +1. Please take this on! https://issues.dlang.org/show_bug.cgi?id=17183

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 20:03:13 UTC, Jonathan M Davis wrote: That being said, at some point, you have to ask whether each added feature is worth the cost when you consider how it's going to clutter up function signatures even further. And while I do think that there is value in DIP

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tue, Feb 14, 2017 at 12:46:17PM -0800, Walter Bright via Digitalmars-d wrote: [...] > Range remove > (SwapStrategy s = SwapStrategy.stable, Range, Offset...) > (Range range, Offset offset) > if (s != SwapStrategy.stable > && isBidirectionalRange!Range > &&

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 16:25:17 UTC, Andrei Alexandrescu wrote: Range remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset) if (s != SwapStrategy.stable && isBidirectionalRange!Range && hasLvalueElements!Range && hasLength!Range &&

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2/14/2017 12:46 PM, Walter Bright wrote: A further improvement in the documentation would be to add links to isBidirectionalRange and hasLvalueElements. For reference: http://dlang.org/phobos/std_algorithm_mutation.html#.remove

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2/14/2017 8:25 AM, Andrei Alexandrescu wrote: Range remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset) if (s != SwapStrategy.stable && isBidirectionalRange!Range && hasLvalueElements!Range && hasLength!Range && Offset.length >= 1);

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, February 14, 2017 09:37:39 Andrei Alexandrescu via Digitalmars-d wrote: > On 02/14/2017 04:55 AM, Jacob Carlborg wrote: > > The signatures we already have in Phobos is quite ridiculous > > How are they so, and what steps can we take to improve them. Could you > please give a few

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 19:27:36 UTC, Adam D. Ruppe wrote: But the problems is: what name do you give it? Quite often it would just be `fooConstraint` or `removable` or other non-reusable things... you'd just be *adding* complication because you'd need to forward all the arguments and

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 19:15:06 UTC, H. S. Teoh wrote: This is already possible: enum fooConstraint(R) = isBidirectionalRange!Range && hasLvalueElements!Range && ... ; Range remove(SwapStrategy s, R)(...) if (fooConstraint!R) { ... } T

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 19:08:53 UTC, bachmeier wrote: I am not familiar with all of the past discussion of this issue, but something that I have wondered is why we can't do something like alias fooConstraint = (s != SwapStrategy.stable You can do that, it would just be a helper

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 19:08:53 UTC, bachmeier wrote: I am not familiar with all of the past discussion of this issue, but something that I have wondered is why we can't do something like Because at that point, it's no longer a set of lego's being put together (design by

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tue, Feb 14, 2017 at 07:14:08PM +, bachmeier via Digitalmars-d wrote: > On Tuesday, 14 February 2017 at 19:08:53 UTC, bachmeier wrote: > > > I am not familiar with all of the past discussion of this issue, but > > something that I have wondered is why we can't do something like > > > >

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 19:08:53 UTC, bachmeier wrote: I am not familiar with all of the past discussion of this issue, but something that I have wondered is why we can't do something like alias fooConstraint = (s != SwapStrategy.stable && isBidirectionalRange!Range &&

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 16:25:17 UTC, Andrei Alexandrescu wrote: Range remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset) if (s != SwapStrategy.stable && isBidirectionalRange!Range && hasLvalueElements!Range && hasLength!Range &&

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 09:55:51 UTC, Jacob Carlborg wrote: Why? It looks awful. The signatures we already have in Phobos is quite ridiculous, this will not improve. Isn't this and the whole idea of DIP 1005 just a workaround for the compiler not lazily analyzing the symbols.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 14:37:39 UTC, Andrei Alexandrescu wrote: what steps can we take to improve them. You really can't unfortunately. Verbose-ness is a nessesary component of type-safe duck typing.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 02/14/2017 10:49 AM, Jacob Carlborg wrote: On 2017-02-14 15:37, Andrei Alexandrescu wrote: How are they so, Example [1]. That signature spans 8 lines, it took me 10 seconds to find the actual function name. Copying here to make things easier: Range remove (SwapStrategy s =

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2017-02-14 15:37, Andrei Alexandrescu wrote: How are they so, Example [1]. That signature spans 8 lines, it took me 10 seconds to find the actual function name. Example [2], 5 lines. Adding attributes on top of that would increase the length of the signature even more. Fortunately

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 02/14/2017 04:55 AM, Jacob Carlborg wrote: The signatures we already have in Phobos is quite ridiculous How are they so, and what steps can we take to improve them. Could you please give a few examples on how to do things better? Thx! -- Andrei

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 09:55:51 UTC, Jacob Carlborg wrote: On 2017-02-14 04:49, Timothee Cour via Digitalmars-d wrote: What about allowing syntax sugar as an alternative to relying on the new `from/Module` inline import idiom: ``` void fun(T)(std.stdio::File input, T value) if

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

Am Tue, 14 Feb 2017 10:23:51 + schrieb Daniel N : > On Tuesday, 14 February 2017 at 10:21:03 UTC, Johannes Pfau wrote: > > Am Mon, 13 Feb 2017 19:49:28 -0800 > > schrieb Timothee Cour via Digitalmars-d > > : > > > >> What about allowing syntax

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 09:55:51 UTC, Jacob Carlborg wrote: Why? It looks awful. The signatures we already have in Phobos is quite ridiculous, this will not improve. Isn't this and the whole idea of DIP 1005 just a workaround for the compiler not lazily analyzing the symbols. This.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, February 14, 2017 10:55:51 Jacob Carlborg via Digitalmars-d wrote: > On 2017-02-14 04:49, Timothee Cour via Digitalmars-d wrote: > > What about allowing syntax sugar as an alternative to relying on the new > > `from/Module` inline import idiom: > > > > ``` > > void

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

Dne 14.2.2017 v 11:21 Johannes Pfau via Digitalmars-d napsal(a): Am Mon, 13 Feb 2017 19:49:28 -0800 schrieb Timothee Cour via Digitalmars-d : What about allowing syntax sugar as an alternative to relying on the new `from/Module` inline import idiom: ``` void

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 10:23:51 UTC, Daniel N wrote: -- Johannes my_module:File is it a label followed by File or File inside my_module? This would be unambiguous AFAIK, since labels can't start with "import." import.my_module:File

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 10:21:03 UTC, Johannes Pfau wrote: Am Mon, 13 Feb 2017 19:49:28 -0800 schrieb Timothee Cour via Digitalmars-d : What about allowing syntax sugar as an alternative to relying on the new `from/Module` inline import idiom: ``` void

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

Am Mon, 13 Feb 2017 19:49:28 -0800 schrieb Timothee Cour via Digitalmars-d : > What about allowing syntax sugar as an alternative to relying on the > new `from/Module` inline import idiom: > > ``` > void fun(T)(std.stdio::File input, T value) if >

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 09:55:51 UTC, Jacob Carlborg wrote: Why? It looks awful. The signatures we already have in Phobos is quite ridiculous, this will not improve. Isn't this and the whole idea of DIP 1005 just a workaround for the compiler not lazily analyzing the symbols. Even

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On 2017-02-14 04:49, Timothee Cour via Digitalmars-d wrote: What about allowing syntax sugar as an alternative to relying on the new `from/Module` inline import idiom: ``` void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T) {...} ``` instead of: ``` void

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

Please fix your newsreader client to send as text, not as html. The html is both excessively large, and has randomly changing fonts embedded in it.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

`#std.stdio.File` doesn't work, we don't know where is the module separator: that could mean `module std` with a class stdio with a field File. so the syntax would have be: `std.stdio SYMBOL File` frankly I don't care which symbol, so long it looks like that. And as I said, `std.stdio::File` is

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 03:49:28 UTC, Timothee Cour wrote: What about allowing syntax sugar as an alternative to relying on the new `from/Module` inline import idiom: ``` void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T) {...} ``` instead of: ``` void

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

as for language change, I believe the proposed syntax (`::`) can be reduced to a minimum if we we make `fullyqualifiedName` `::` a reduction to the from/Module inline import idiom. No complex corner case or new bug introduced, it could be done as a pure AST transformation On Mon, Feb 13, 2017 at

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

> The only thing from has going for it is that it doesn't require a language change. Yours does, so it should be compared to the proposals in DIP1005 and not just from. indeed. But just because something can be done in library code doesn't mean it should. Same exact rationale for: `lazy`, `=>`,

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 03:49:28 UTC, Timothee Cour wrote: What about allowing syntax sugar as an alternative to relying on the new `from/Module` inline import idiom: ``` void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T) {...} ``` instead of: ``` void

syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

What about allowing syntax sugar as an alternative to relying on the new `from/Module` inline import idiom: ``` void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T) {...} ``` instead of: ``` void fun(T)(Module!"std.stdio".File input, T value) if