www.digitalmars.com         C & C++   DMDScript  

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

reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
(Module!"std.traits".isIntegral!T) {...}
```

Rationale:

* this reads much better (less noise); same as `=>` syntax for lambdas

* this is expected to be a very common pattern, so might as well make it as
simple as possible

* not particular on which symbol is used, could be something else, so long
it doesn't involve writing a string such as from!"std.traits". But :: will
be familiar to those coming from C++/rust etc.

* from!"" is too loose and can be abused arbitrarily:

```
// this compiles
void fun(){
  from!"std.stdio; pragma(msg,`abuse...`); import std.stdio".File a;
}
```

Furthermore this is useful in other scenarios, namely when an import is
used only once in a context:
```
auto fun(){  return std.file::getcwd; }
```
is more DRY; instead of:
```
auto fun(){ static import std.file;  return std.file.getcwd; }
auto fun(){ return Module!"std.file".getcwd; }
```

NOTE: if :: is not feasible for whatever reason, let's consider other
symbols without prejudice to this proposal.
Feb 13
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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 fun(T)(Module!"std.stdio".File input, T value) if
 (Module!"std.traits".isIntegral!T) {...}
 ```

 Rationale:

 * this reads much better (less noise); same as `=>` syntax for 
 lambdas

 * this is expected to be a very common pattern, so might as 
 well make it as simple as possible

 * not particular on which symbol is used, could be something 
 else, so long it doesn't involve writing a string such as 
 from!"std.traits". But :: will be familiar to those coming from 
 C++/rust etc.

 * from!"" is too loose and can be abused arbitrarily:

 ```
 // this compiles
 void fun(){
   from!"std.stdio; pragma(msg,`abuse...`); import 
 std.stdio".File a;
 }
 ```

 Furthermore this is useful in other scenarios, namely when an 
 import is
 used only once in a context:
 ```
 auto fun(){  return std.file::getcwd; }
 ```
 is more DRY; instead of:
 ```
 auto fun(){ static import std.file;  return std.file.getcwd; }
 auto fun(){ return Module!"std.file".getcwd; }
 ```

 NOTE: if :: is not feasible for whatever reason, let's consider 
 other symbols without prejudice to this proposal.
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. TBQH all the the proposed syntaxes for the DIP1005 problem kind of suck, because at the end of the day there's no good way to solve the problem. Every proposed solution either 1. Looks terrible (and some people highly underestimate the cost of a language looking bad), or 2. Complicate our already complex function definitions even further. How is a beginner not going to look at this and feel like barfing with (import std.datetime, std.range.primitives) void fun(R)(scope R r, const ref Systime value) if (isInputRange!R && !isFinite!R) { ... } But, I'm still of the opinion that the `with` syntax is currently the best proposal. Others have already shown the weaknesses of the `from!` approach.
Feb 13
next sibling parent Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
 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`, `=>`, scope(exit), etc. All of these coul've been done in pure library code, but the syntax sugar makes them particularly easy to use. Syntax sugar should be used sparingly, but it makes sense if * it simplifies syntax compared to best possible library code * it's for a common use case On Mon, Feb 13, 2017 at 9:03 PM, Jack Stouffer via Digitalmars-d < digitalmars-d puremagic.com> wrote:
 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 fun(T)(Module!"std.stdio".File input, T value) if
 (Module!"std.traits".isIntegral!T) {...}
 ```

 Rationale:

 * this reads much better (less noise); same as `=>` syntax for lambdas

 * this is expected to be a very common pattern, so might as well make it
 as simple as possible

 * not particular on which symbol is used, could be something else, so
 long it doesn't involve writing a string such as from!"std.traits". But ::
 will be familiar to those coming from C++/rust etc.

 * from!"" is too loose and can be abused arbitrarily:

 ```
 // this compiles
 void fun(){
   from!"std.stdio; pragma(msg,`abuse...`); import std.stdio".File a;
 }
 ```

 Furthermore this is useful in other scenarios, namely when an import is
 used only once in a context:
 ```
 auto fun(){  return std.file::getcwd; }
 ```
 is more DRY; instead of:
 ```
 auto fun(){ static import std.file;  return std.file.getcwd; }
 auto fun(){ return Module!"std.file".getcwd; }
 ```

 NOTE: if :: is not feasible for whatever reason, let's consider other
 symbols without prejudice to this proposal.
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. TBQH all the the proposed syntaxes for the DIP1005 problem kind of suck, because at the end of the day there's no good way to solve the problem. Every proposed solution either 1. Looks terrible (and some people highly underestimate the cost of a language looking bad), or 2. Complicate our already complex function definitions even further. How is a beginner not going to look at this and feel like barfing with (import std.datetime, std.range.primitives) void fun(R)(scope R r, const ref Systime value) if (isInputRange!R && !isFinite!R) { ... } But, I'm still of the opinion that the `with` syntax is currently the best proposal. Others have already shown the weaknesses of the `from!` approach.
Feb 13
prev sibling parent reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 9:32 PM, Timothee Cour <thelastmammoth gmail.com>
wrote:

 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`, `=>`, scope(exit), etc. All of these coul've been done in pure library code, but the syntax sugar makes them particularly easy to use. Syntax sugar should be used sparingly, but it makes sense if * it simplifies syntax compared to best possible library code * it's for a common use case On Mon, Feb 13, 2017 at 9:03 PM, Jack Stouffer via Digitalmars-d < digitalmars-d puremagic.com> wrote:
 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 fun(T)(Module!"std.stdio".File input, T value) if
 (Module!"std.traits".isIntegral!T) {...}
 ```

 Rationale:

 * this reads much better (less noise); same as `=>` syntax for lambdas

 * this is expected to be a very common pattern, so might as well make it
 as simple as possible

 * not particular on which symbol is used, could be something else, so
 long it doesn't involve writing a string such as from!"std.traits". But ::
 will be familiar to those coming from C++/rust etc.

 * from!"" is too loose and can be abused arbitrarily:

 ```
 // this compiles
 void fun(){
   from!"std.stdio; pragma(msg,`abuse...`); import std.stdio".File a;
 }
 ```

 Furthermore this is useful in other scenarios, namely when an import is
 used only once in a context:
 ```
 auto fun(){  return std.file::getcwd; }
 ```
 is more DRY; instead of:
 ```
 auto fun(){ static import std.file;  return std.file.getcwd; }
 auto fun(){ return Module!"std.file".getcwd; }
 ```

 NOTE: if :: is not feasible for whatever reason, let's consider other
 symbols without prejudice to this proposal.
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. TBQH all the the proposed syntaxes for the DIP1005 problem kind of suck, because at the end of the day there's no good way to solve the problem. Every proposed solution either 1. Looks terrible (and some people highly underestimate the cost of a language looking bad), or 2. Complicate our already complex function definitions even further. How is a beginner not going to look at this and feel like barfing with (import std.datetime, std.range.primitives) void fun(R)(scope R r, const ref Systime value) if (isInputRange!R && !isFinite!R) { ... } But, I'm still of the opinion that the `with` syntax is currently the best proposal. Others have already shown the weaknesses of the `from!` approach.
Feb 13
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 14
prev sibling next sibling parent reply Chris M <chrismohrfeld comcast.net> writes:
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 fun(T)(Module!"std.stdio".File input, T value) if
 (Module!"std.traits".isIntegral!T) {...}
 ```

 Rationale:

 * this reads much better (less noise); same as `=>` syntax for 
 lambdas

 * this is expected to be a very common pattern, so might as 
 well make it as simple as possible

 * not particular on which symbol is used, could be something 
 else, so long it doesn't involve writing a string such as 
 from!"std.traits". But :: will be familiar to those coming from 
 C++/rust etc.

 * from!"" is too loose and can be abused arbitrarily:

 ```
 // this compiles
 void fun(){
   from!"std.stdio; pragma(msg,`abuse...`); import 
 std.stdio".File a;
 }
 ```

 Furthermore this is useful in other scenarios, namely when an 
 import is
 used only once in a context:
 ```
 auto fun(){  return std.file::getcwd; }
 ```
 is more DRY; instead of:
 ```
 auto fun(){ static import std.file;  return std.file.getcwd; }
 auto fun(){ return Module!"std.file".getcwd; }
 ```

 NOTE: if :: is not feasible for whatever reason, let's consider 
 other symbols without prejudice to this proposal.
Well, as Jack said there's no real clean way to do this without cluttering the function signatures more. However if this does happen through a language change, :: would look kind of awkward imo. I'd go with the following idea instead. void fun(T)(#std.stdio.File input, T value) if (#std.traits.isIntegral!T) {...} Doesn't necessarily have to be the octothorpe, but I think it looks a bit cleaner.
Feb 13
parent Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
`#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 reasonable since it's used for similar purpose
in rust and C++



On Mon, Feb 13, 2017 at 10:21 PM, Chris M via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 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 fun(T)(Module!"std.stdio".File input, T value) if
 (Module!"std.traits".isIntegral!T) {...}
 ```

 Rationale:

 * this reads much better (less noise); same as `=>` syntax for lambdas

 * this is expected to be a very common pattern, so might as well make it
 as simple as possible

 * not particular on which symbol is used, could be something else, so
 long it doesn't involve writing a string such as from!"std.traits". But ::
 will be familiar to those coming from C++/rust etc.

 * from!"" is too loose and can be abused arbitrarily:

 ```
 // this compiles
 void fun(){
   from!"std.stdio; pragma(msg,`abuse...`); import std.stdio".File a;
 }
 ```

 Furthermore this is useful in other scenarios, namely when an import is
 used only once in a context:
 ```
 auto fun(){  return std.file::getcwd; }
 ```
 is more DRY; instead of:
 ```
 auto fun(){ static import std.file;  return std.file.getcwd; }
 auto fun(){ return Module!"std.file".getcwd; }
 ```

 NOTE: if :: is not feasible for whatever reason, let's consider other
 symbols without prejudice to this proposal.
Well, as Jack said there's no real clean way to do this without cluttering the function signatures more. However if this does happen through a language change, :: would look kind of awkward imo. I'd go with the following idea instead. void fun(T)(#std.stdio.File input, T value) if (#std.traits.isIntegral!T) {...} Doesn't necessarily have to be the octothorpe, but I think it looks a bit cleaner.
Feb 13
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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 fun(T)(Module!"std.stdio".File input, T value) if
 (Module!"std.traits".isIntegral!T) {...}
 ```

 Rationale:

 * this reads much better (less noise); same as `=>` syntax for lambdas

 * this is expected to be a very common pattern, so might as well make it
 as simple as possible
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. -- /Jacob Carlborg
Feb 14
next sibling parent Daniel N <no public.email> writes:
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 those of you who favor... with(import std.stdio) ... wouldn't you agree that this is better? with(Module!"std.stdio") Less intrusive compiler change because the same syntax already works everywhere "with" is valid.
Feb 14
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 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) {...}
 ```

 Rationale:

 * this reads much better (less noise); same as `=>` syntax for lambdas

 * this is expected to be a very common pattern, so might as well make it
 as simple as possible
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.
Mostly, but not just that. By having something like DIP 1005, all of the imports required for the function can be associated with the function. So, people reading the code then have an easier time figuring out where the symbols come from, and it could be that the compiler could take advantage of that somehow. It does seem though that the main motivator for DIP 1005 is the fact that we don't have lazy imports, and Walter has talked before about wanting to do fully lazy imports. So, I expect that we'll get them at some point, at which point, any performance improvements from DIP 1005 or the from template would likely become moot, and the only benefit left is essentially documentation. Personally, I might use DIP 1005 in some cases if we end up with it, but I won't use from unless I'm forced to. As cool as it is that we can do it with the language as-is, it's far too verbose and far too ugly. As it is, I'm getting sick of doing local and selective imports all over the place like everyone seems to think is best practice. I understand why they're theoretically good, but it results in longer code, and it gets very tedious to have to try and maintain the list of symbols that are imported instead of just importing the modules you need at the top of the module and forgetting about it. Doing what DIP 1005 and from push for just takes that pain to another level. It might be worth it in code used by tons of people (like Phobos), but for most code, I'm increasingly of the opinion that it's not worth it. And having proper lazy imports would largely fix the compilation cost of simply importing modules. So, I'm very much in favor of getting lazy imports, and while I do see _some_ value in documenting where stuff comes from via something like DIP 1005, I seriosuly question that it's worth the extra pain. And when you have all of those function attributes to worry about on top of that... It's just getting to be too much. - Jonathan M Davis
Feb 14
prev sibling next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
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.
Feb 14
prev sibling next sibling parent Meta <jared771 gmail.com> writes:
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
 (std.traits::isIntegral!T) {...}
 ```

 instead of:

 ```
 void fun(T)(Module!"std.stdio".File input, T value) if
 (Module!"std.traits".isIntegral!T) {...}
 ```

 Rationale:

 * this reads much better (less noise); same as `=>` syntax for 
 lambdas

 * this is expected to be a very common pattern, so might as 
 well make it
 as simple as possible
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 is what I had thought as well when Andrei first posted DIP1005, but he said that his main goal is actually making it so a declaration can carry all of its imports with it in a self-contained unit. When you look at it that way it makes a bit more sense as to why we might want constructs such as introduced by DIP1005 or this self-important lookup idiom.
Feb 14
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 14
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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 templates will infer most attributes.
 and what steps can we take to improve them. Could you
 please give a few examples on how to do things better? Thx! -- Andrei
Well, I would prefer to have template constraints as its own entity in the language not not just a bunch of boolean conditions. This has been talked about before several times. Something like: constraint Foo { void foo(); } void bar(T : Foo)(T t); [1] https://github.com/dlang/phobos/blob/master/std/algorithm/mutation.d#L1682-L1689 [2] https://github.com/dlang/phobos/blob/master/std/algorithm/mutation.d#L2729-L2733 -- /Jacob Carlborg
Feb 14
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset) if (s != SwapStrategy.stable && isBidirectionalRange!Range && hasLvalueElements!Range && hasLength!Range && Offset.length >= 1); The function name is on the first line. I think 10 seconds would be an exaggeration of an admittedly real issue.
 Example [2], 5 lines.
Copying here as well (reflowed for email): Tuple!(InputRange1, InputRange2) swapRanges(InputRange1, InputRange2)(InputRange1 r1, InputRange2 r2) if (isInputRange!(InputRange1) && isInputRange!(InputRange2) && hasSwappableElements!(InputRange1) && hasSwappableElements!(InputRange2) && is(ElementType!(InputRange1) == ElementType!(InputRange2))); One immediate matter here is redundant parens, of which elimination would lead to the marginally more palatable: Tuple!(InputRange1, InputRange2) swapRanges(InputRange1, InputRange2)(InputRange1 r1, InputRange2 r2) if (isInputRange!InputRange1 && isInputRange!InputRange2 && hasSwappableElements!InputRange1 && hasSwappableElements!InputRange2 && is(ElementType!InputRange1 == ElementType!InputRange2));
 and what steps can we take to improve them. Could you
 please give a few examples on how to do things better? Thx! -- Andrei
Well, I would prefer to have template constraints as its own entity in the language not not just a bunch of boolean conditions. This has been talked about before several times. Something like: constraint Foo { void foo(); } void bar(T : Foo)(T t);
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 possible.) Before long there is an explosion in names ("BidirectionalWithLvalueElementsAndLength", ...). This is what has buried not one, but two concepts proposals for C++, leading to the current Concepts Lite proposal. I haven't followed that lately but I remember it combines an engineering effort to reduce the number of names introduced (for the standard library only, which is a limitation) with adding support to Boolean logic (surprise, surprise) to the feature (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4377.pdf), the most recent proposal, which was rejected for C++17. Over time, C++ concepts have moved from the broken combinatorially-bankrupt form slowly toward D's Boolean constraints (just with a gratuitously awkward notation). I presume they will be merged into the language when they'll have capabilities comparable to D's system. The question is, given this experience, do we want to move the opposite direction? Andrei
Feb 14
next sibling parent reply bachmeier <no spam.net> writes:
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
     && Offset.length >= 1);
[...]
 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 
 possible.) Before long there is an explosion in names 
 ("BidirectionalWithLvalueElementsAndLength", ...). This is what 
 has buried not one, but two concepts proposals for C++, leading 
 to the current Concepts Lite proposal. I haven't followed that 
 lately but I remember it combines an engineering effort to 
 reduce the number of names introduced (for the standard library 
 only, which is a limitation) with adding support to Boolean 
 logic (surprise, surprise) to the feature (see 
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4377.pdf), the most
recent proposal, which was rejected for C++17. Over time, C++ concepts have
moved from the broken combinatorially-bankrupt form slowly toward D's Boolean
constraints (just with a gratuitously awkward notation). I presume they will be
merged into the language when they'll have capabilities comparable to D's
system.

 The question is, given this experience, do we want to move the 
 opposite direction?
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 && hasLvalueElements!Range && hasLength!Range && Offset.length >= 1); Range remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset) if fooConstraint;
Feb 14
next sibling parent reply bachmeier <no spam.net> writes:
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
   && hasLvalueElements!Range
   && hasLength!Range
   && Offset.length >= 1);

 Range remove
   (SwapStrategy s = SwapStrategy.stable, Range, Offset...)
   (Range range, Offset offset) if fooConstraint;
I mean, is there some reason that this shouldn't be allowed? Any feature can be abused, but it looks useful in many cases.
Feb 14
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Feb 14, 2017 at 07:14:08PM +0000, 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
 
 alias fooConstraint = (s != SwapStrategy.stable
   && isBidirectionalRange!Range
   && hasLvalueElements!Range
   && hasLength!Range
   && Offset.length >= 1);
 
 Range remove
   (SwapStrategy s = SwapStrategy.stable, Range, Offset...)
   (Range range, Offset offset) if fooConstraint;
I mean, is there some reason that this shouldn't be allowed? Any feature can be abused, but it looks useful in many cases.
This is already possible: enum fooConstraint(R) = isBidirectionalRange!Range && hasLvalueElements!Range && ... ; Range remove(SwapStrategy s, R)(...) if (fooConstraint!R) { ... } T -- "Maybe" is a strange word. When mom or dad says it it means "yes", but when my big brothers say it it means "no"! -- PJ jr.
Feb 14
parent bachmeier <no spam.net> writes:
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
That's good to know. I didn't try that syntax, though, which explains why I couldn't get it to work.
Feb 14
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
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 introspection) which build a larger whole. It's the genericism problem of requiring a name for everything. At the end of the day this would actually make constraints less *verbose*, but more *complicated*.
Feb 14
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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 function / template instead of an alias. You can use the shorthand enum syntax: enum removable(R) = isBidirectionalRange!R && isInputRange!R; Range remove(Range)(Range r) if(removable!Range) { return r; } That works today. 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 write different ones for each function anyway. There's a few common cases we might combine, like Phobos often uses `isInputRange!Range && is(ElementType!Range == Something)` and perhaps that could be combined into `isInputRangeOf!(Range, Something)` or something like that, but in many cases, there'd be an equal number of aliases constraints to existing inline ones anyway....
Feb 14
parent bachmeier <no spam.net> writes:
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 write 
 different ones for each function anyway.

 There's a few common cases we might combine, like Phobos often 
 uses `isInputRange!Range && is(ElementType!Range == Something)` 
 and perhaps that could be combined into `isInputRangeOf!(Range, 
 Something)` or something like that, but in many cases, there'd 
 be an equal number of aliases constraints to existing inline 
 ones anyway....
Makes sense. I had assumed there would be a lot of duplication of constraints.
Feb 14
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Tue, 14 Feb 2017 19:08:53 +0000, 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 && hasLvalueElements!Range &&
    hasLength!Range && Offset.length >= 1);
 
 Range remove
    (SwapStrategy s = SwapStrategy.stable, Range, Offset...)
    (Range range, Offset offset) if fooConstraint;
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. If the entirety of the constraint is in the body of that helper template, that's a step up from what we have today. But that would involve code duplication, which people tend to dislike.
Feb 14
parent bachmeier <no spam.net> writes:
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 this thread suggests that's the main reason others read source code. My opinion is that inlining the constraints greatly detracts from readability and provides little benefit in return. I also don't understand the problem with using simple names.
Feb 15
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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);

 The function name is on the first line.
It could be improved slightly using indentation: 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); But there's another issue here. remove() has other overloads: Range remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset) if (s == SwapStrategy.stable && isBidirectionalRange!Range && hasLvalueElements!Range && Offset.length >= 1) Range remove(alias pred, SwapStrategy s = SwapStrategy.stable, Range) (Range range) if (isBidirectionalRange!Range && hasLvalueElements!Range) 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 body under `static if`, as the user need not be concerned with them. This is a general issue in Phobos that too many constraints are user-facing when they don't need to be. A further improvement in the documentation would be to add links to isBidirectionalRange and hasLvalueElements.
Feb 14
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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
Feb 14
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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
         && hasLvalueElements!Range
         && hasLength!Range
         && Offset.length >= 1);
 
 But there's another issue here. remove() has other overloads:
 
 Range remove
     (SwapStrategy s = SwapStrategy.stable, Range, Offset...)
     (Range range, Offset offset)
     if (s == SwapStrategy.stable
         && isBidirectionalRange!Range
         && hasLvalueElements!Range
         && Offset.length >= 1)
 
 Range remove(alias pred, SwapStrategy s = SwapStrategy.stable, Range)
     (Range range)
     if (isBidirectionalRange!Range
         && hasLvalueElements!Range)
 
 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 body
 under `static if`, as the user need not be concerned with them.
 
 This is a general issue in Phobos that too many constraints are
 user-facing when they don't need to be.
+1. I've raised this point many times, but didn't seem to generate much response. Basically, there are two more-or-less equivalent ways of having multiple implementations of a function based on its arguments: (1) via signature constraints, and (2) via static if's inside the function (or template) body.
From an implementor's POV, (1) is more desirable, because it's easy to
add a new overload when you need to extend the function to handle new types. However, from a user's POV, (2) is much more friendly -- one only needs to look at the old overloads of std.conv.toImpl to see why: it was an obtuse mass of only slightly different sig constraints over a ridiculous number of overloads, each intended to work with very specific argument combinations, all of which are implementation details the user need not know about. 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 hidden behind module-private overloads. This is the way it should be. I argue that the same pattern should be applied to (most of the) other overloaded Phobos functions as well, such as remove() shown above. There really should only be *one* remove() function with the two constraints Walter indicated, and the current overloads should either be refactored under static if's inside the function body, or else renamed and made into module-private implementation functions called by remove(). Multiple user-facing overloads really only should be used where each overload represents a *conceptually-different* aspect of the function (which should be relatively rare). In general, if a template function (or set of overloads) conceptually does the same thing, it should be made into a *single* function. If the implementation differs, that's the problem of the Phobos maintainers, and should be handled as module-private symbols forwarded to by the single user-facing function. Another bonus to this approach is that it allows us to customize nicer error messages via static assert if none of the (internal) overloads match the passed argument types. E.g., if the user passes a swappable bidirectional range to remove() but for whatever reason the arguments fail to match any of its implementations, then instead of spewing out pages of inscrutable encrypted Klingon (argument types XYZ do not match any overloads of remove(), candidates are: [... snip 5 pages of unreadable function signatures...]), we can, say, do something like: static if (...) return removeImplA(args); else static if (...) return removeImplB(args); ... else static assert("Arguments to remove() must satisfy conditions X, Y, Z [insert explanation here]"); That's a 1-line error message that tells the user exactly what went wrong, instead of 5 pages of 10-line function signatures that the user must parse and then mentally evaluate each Boolean condition for, in order to deduce exactly why the passed arguments didn't work.
 A further improvement in the documentation would be to add links to
 isBidirectionalRange and hasLvalueElements.
This is a good idea. +1. T -- "I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly
Feb 14
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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
Feb 14
prev sibling parent Jack Stouffer <jack jackstouffer.com> writes:
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 hidden behind 
 module-private overloads. This is the way it should be.
I'm currently trying to do this again in std.format, this is the first step: https://github.com/dlang/phobos/pull/5130
Feb 15
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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 this insane automatic cross referencing: http://dpldocs.info/experimental-docs/std.range.chain.html My ref thing still isn't perfect, but dpldocs is already streets ahead of anything dlang.org has to offer and continues to make bursts of strides.
Feb 14
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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, but dpldocs is already streets ahead
 of anything dlang.org has to offer and continues to make bursts of strides.
Your documentation is an improvement but it doesn't help when reading the source code. -- /Jacob Carlborg
Feb 14
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
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 committing to spend at least thirty minutes on it. 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. This doc improvement means I only have to go to dpldocs.info (which I'm probably already at), search for the term, and click a few times. I don't have to pull out grep, peer myopically through the pages of results, and figure out which ones are the definitions of the template constraints I need.
Feb 15
parent Adam D. Ruppe <destructionator gmail.com> writes:
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 compiler would tell you at least which part of the boolean expression failed. Then, at least, you could dig deeper with your own static asserts on those individual things or something. tbh I actually want opt-in XML error messages with obscene levels of detail. We'd pwn IDE integration with that and can really save programmers wads of time by giving them all the info they actually need. D used to promote its readable error messages as a strength over C++. We've fallen far behind in that category now. This doc improvement means I only have to go to
 dpldocs.info (which I'm probably already at), search for the 
 term, and click a few times.
indeed, I'm pretty happy with my navigation. And I'm slowly but surely fixing the automatic cross referencing. D name lookup across modules is kinda hard, this is one place dmd/ddoc would have a strong theoretical advantage since it understands the semantics and already knows the module graph. But, I'm already 80% there... and it is yielding pretty great results in practice. I'll do alias lookups next time I spend a few hours on this (tbh since it is good enough for me, it is all low priority relative to the other things I have to do, so it is moving slowly now.)
Feb 15
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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 said before, isInputRangeOf is potentially useful. Though, like Andrei, I'm skeptical on doing too much of that, since the combinations can quickly explode and then you just have to search through more to figure out wtf they mean. That'd help the source and docs if we find the right balance.
Feb 15
next sibling parent reply Seb <seb wilzba.ch> writes:
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 should find the common combinations and abstract them out, like I said before, isInputRangeOf is potentially useful. Though, like Andrei, I'm skeptical on doing too much of that, since the combinations can quickly explode and then you just have to search through more to figure out wtf they mean. That'd help the source and docs if we find the right balance.
Speaking of right balance, there's currently a PR at Phobos that is a good candidate to get a common measure on how this balance should be set: https://github.com/dlang/phobos/pull/5132 The open question here is that for nearly every function in std.file & std.path the constraint block looks like this: 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: enum isSomeInputRangeChar(R) = isInputRange!R && !isInfinite!R && isSomeChar!(ElementEncodingType!R) && !isConvertibleToString!R which would obviously lead to: uint getAttributes(R)(R name) if (isSomeInputRangeChar!R) What's your opinion on such a case?
Feb 15
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
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 (isSomeInputRangeChar!R)

 What's your opinion on such a case?
Yeah, I'd say do it, and it is similar to isSomeString in use elsewhere.
Feb 15
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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:
isStringLike. I wanted to add this for a while already. Please do! -- Andrei
Feb 15
next sibling parent Seb <seb wilzba.ch> writes:
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 one could argue 
 that it
 makes sense to use a convenience trait like:
isStringLike. I wanted to add this for a while already. Please do! -- Andrei
https://github.com/dlang/phobos/pull/5137
Feb 15
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 arrays 3. static arrays 4. aggregates with an 'alias this' to a string 5. ranges of characters 6. something convertible to a string These classifications seem to be tested for in a unique ad-hoc manner in every case. I'd like to take a step back and devise a consistent taxonomy of these things, based on how Phobos uses them, before adding more names.
Feb 15
next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 are at least 6 kinds of strings: 1. auto decoding dynamic arrays 2. not auto decoding arrays 3. static arrays 4. aggregates with an 'alias this' to a string 5. ranges of characters 6. something convertible to a string These classifications seem to be tested for in a unique ad-hoc manner in every case. I'd like to take a step back and devise a consistent taxonomy of these things, based on how Phobos uses them, before adding more names.
Yeah. It's a bit of a mess. And types with alias this and enums _really_ don't help things. - Jonathan M Davis
Feb 15
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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 anything other than "static arrays"? Also, they're not ranges, so they're usually tested with isStaticArray
 4. aggregates with an 'alias this' to a string
isConvertibleToString
 5. ranges of characters
Character range
 6. something convertible to a string
Same as 4
Feb 15
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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. static arrays
Do these need to be called anything other than "static arrays"? Also, they're not ranges, so they're usually tested with isStaticArray
 4. aggregates with an 'alias this' to a string
isConvertibleToString
 5. ranges of characters
Character range
 6. something convertible to a string
Same as 4
That's a good start. A test of that is to look at Phobos' actual usage of constraints and see if they fit in.
Feb 15
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 strings
 2. not auto decoding arrays
Wide strings
 3. static arrays
Do these need to be called anything other than "static arrays"? Also, they're not ranges, so they're usually tested with isStaticArray
 4. aggregates with an 'alias this' to a string
isConvertibleToString
 5. ranges of characters
Character range
 6. something convertible to a string
Same as 4
Except that you're forgetting enums. Also, there's this mess: enum bool isNarrowString(T) = (is(T : const char[]) || is(T : const wchar[])) && !isAggregateType!T && !isStaticArray!T; enum bool isAutodecodableString(T) = (is(T : const char[]) || is(T : const wchar[])) && !isStaticArray!T; A type with alias this passes isAutodecodableString but not isNarrowString, making for really subtle difference. Also, enums of strings pass both, which is potentially a problem as they really should be treated the same as types with alias this given how they need to be used in a templated function. enums also pass isSomeString, which makes using isSomeString a no-go for any range-based function if it doesn't then test for enums - but aggregate types _don't_ pass isSomeString. And then there's template isConvertibleToString(T) { enum isConvertibleToString = (isAggregateType!T || isStaticArray!T || is(T == enum)) && is(StringTypeOf!T); } 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 the right one as well as testing with various types that frequently get missed in unit tests - like types which use alias this or enums with a base type of string. - Jonathan M Davis
Feb 15
parent Walter Bright <newshound2 digitalmars.com> writes:
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 the right one as well as testing with various types that frequently get
 missed in unit tests - like types which use alias this or enums with a base
 type of string.
I suspect the only way forward is to go through Phobos and collect all the plethora of constraints used for strings, and examine them for commonalities. Not doing this will just result in more accumulation of confusing junk.
Feb 15
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Feb 15, 2017 at 09:03:46PM +0000, 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 strings
 2. not auto decoding arrays
Wide strings
 3. static arrays
Do these need to be called anything other than "static arrays"? Also, they're not ranges, so they're usually tested with isStaticArray
 4. aggregates with an 'alias this' to a string
isConvertibleToString
 5. ranges of characters
Character range
 6. something convertible to a string
Same as 4
This describes the current state of Phobos, but I think what Walter is driving at is, does it *have* to be this way? I think we can (and should) simplify this taxonomy to avoid needless duplication and also create a more consistent conceptual model of how Phobos deals with strings and string-like things. First of all, I think we should try out best to avoid treating arrays and character ranges differently. I know this is inevitable because we're still in a state where autodecoding can't be fully eliminated yet, but as far as possible, I think we should try to treat them the same way. (1) Functions that need to work with string contents (e.g., find, toUpperCase, etc.) should in general accept any input ranges whose elements are convertible in some way to dchar. Some of these functions may require forward ranges or bidirectional / random-access ranges. Most of these functions can allow infinite ranges (so we only need the occasional !isInfinite check). (2) Functions that don't need to work with string contents, i.e., the strings are treated as opaque blobs to be passed to, say, an underlying OS function, require finite ranges, but should be able to work with any type that converts to string in one form or another. So anything from (finite) ranges of char-like elements to aggregates with alias this to string ought to be accepted. They can be internally converted to strings if necessary (e.g., to pass to an OS call). I suspect that many of the functions in category (1) can be coalesced with generic range algorithms, so they should not even be exposing their sig constraints in the public API. Instead, they should take a generic range and then use static if or module-private helper functions to dispatch to the right implementation(s). Category (2) functions can internally call helpers (maybe in std.string or std.array) that convert any incoming type that can be converted to string in some way. As for static arrays, I think the consensus is (was?) that they are not ranges, and so the user is required to take a slice before handing it to a Phobos function expecting string or string-like arguments. Well, actually, not just string-like things, but anything to do with ranges. I don't think there's a need to treat static arrays of char separately from static arrays in general. T -- Bare foot: (n.) A device for locating thumb tacks on the floor.
Feb 15
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 15
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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 should find the common combinations and abstract them out, like I said before, isInputRangeOf is potentially useful. Though, like Andrei, I'm skeptical on doing too much of that, since the combinations can quickly explode and then you just have to search through more to figure out wtf they mean. That'd help the source and docs if we find the right balance.
I submitted a Phobos PR for `isInputRangeOf`. It was nuked from orbit. I understand why: as you mention, the combinatorial explosion of names is an issue. But: it's a mess rangeifying code when this: void fun(Foo[] foos); // yay! readable becomes: void fun(R)(R foos) if(isInputRange!R && is(Unqual!(ElementType!R) == Foo); Ugh. Atila
Feb 16
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 things we can do in the source too. We should find the common combinations and abstract them out, like I said before, isInputRangeOf is potentially useful. Though, like Andrei, I'm skeptical on doing too much of that, since the combinations can quickly explode and then you just have to search through more to figure out wtf they mean. That'd help the source and docs if we find the right balance.
I submitted a Phobos PR for `isInputRangeOf`. It was nuked from orbit. I understand why: as you mention, the combinatorial explosion of names is an issue. But: it's a mess rangeifying code when this: void fun(Foo[] foos); // yay! readable becomes: void fun(R)(R foos) if(isInputRange!R && is(Unqual!(ElementType!R) == Foo);
If you find a number of these, that would be good evidence. -- Andrei
Feb 16
parent reply Atila Neves <atila.neves gmail.com> writes:
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 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 said before, isInputRangeOf is potentially useful. Though, like Andrei, I'm skeptical on doing too much of that, since the combinations can quickly explode and then you just have to search through more to figure out wtf they mean. That'd help the source and docs if we find the right balance.
I submitted a Phobos PR for `isInputRangeOf`. It was nuked from orbit. I understand why: as you mention, the combinatorial explosion of names is an issue. But: it's a mess rangeifying code when this: void fun(Foo[] foos); // yay! readable becomes: void fun(R)(R foos) if(isInputRange!R && is(Unqual!(ElementType!R) == Foo);
If you find a number of these, that would be good evidence. -- Andrei
I found just over 70 similar lines, which is more than I expected given how generic Phobos is. The real issue is in client code though. I write less range-based code than I'd like, because it's a lot easier to make it a regular array and change it later if the function needs to be called with other ranges. Atila
Feb 22
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 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 said before, isInputRangeOf is potentially useful. Though, like Andrei, I'm skeptical on doing too much of that, since the combinations can quickly explode and then you just have to search through more to figure out wtf they mean. That'd help the source and docs if we find the right balance.
I submitted a Phobos PR for `isInputRangeOf`. It was nuked from orbit. I understand why: as you mention, the combinatorial explosion of names is an issue. But: it's a mess rangeifying code when this: void fun(Foo[] foos); // yay! readable becomes: void fun(R)(R foos) if(isInputRange!R && is(Unqual!(ElementType!R) == Foo);
If you find a number of these, that would be good evidence. -- Andrei
I found just over 70 similar lines, which is more than I expected given how generic Phobos is. The real issue is in client code though. I write less range-based code than I'd like, because it's a lot easier to make it a regular array and change it later if the function needs to be called with other ranges.
If you submit a pull request that simplifies >70 constraints in Phobos and implicitly promises to simplify client-level constraints as much, that would have a good chance to be accepted. Destroy! -- Andrei
Feb 22
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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! 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, but dpldocs is already streets ahead of anything dlang.org has to offer and continues to make bursts of strides.
That looks pretty sweet!
Feb 15
parent reply Jacob Carlborg <doob me.com> writes:
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! 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, but dpldocs is already streets ahead of anything dlang.org has to offer and continues to make bursts of strides.
That looks pretty sweet!
Doesn't help when reading the source code :(. -- /Jacob Carlborg
Feb 15
parent reply Daniel N <no public.email> writes:
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
 isBidirectionalRange and hasLvalueElements.
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, but dpldocs is already streets ahead of anything dlang.org has to offer and continues to make bursts of strides.
That looks pretty sweet!
Doesn't help when reading the source code :(.
Something akin to this would improve readability at least for me, also more DRY. isInputRange!(InputRange1) && isInputRange!(InputRange2) && hasSwappableElements!(InputRange1) && hasSwappableElements!(InputRange2) => every!(InputRange1, InputRange2). satisfies!(isInputRange, hasSwappableElements); template every(T...) { template satisfies(U...) { enum satisfies = true; } }
Feb 15
parent reply Daniel N <no public.email> writes:
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 = { foreach(t; T) foreach(u; U) if(!u!t) return false; return true; }(); } }
Feb 15
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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...) { enum satisfies = { foreach(t; T) foreach(u; U) if(!u!t) return false; return true; }(); } }
That looks pretty neat. Can you find 4-5 cases in which this could be used gainfully in Phobos? Thanks! -- Andrei
Feb 15
next sibling parent reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
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)
{...}
```

I see it as a clear improvment in readability (see original post for
details along with shortcomings of `from!` approach )


On Wed, Feb 15, 2017 at 11:39 AM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d puremagic.com> 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 => time to hack D!) template every(T...) { template satisfies(U...) { enum satisfies = { foreach(t; T) foreach(u; U) if(!u!t) return false; return true; }(); } }
That looks pretty neat. Can you find 4-5 cases in which this could be used gainfully in Phobos? Thanks! -- Andrei
Feb 15
next sibling parent reply Nick Treleaven <nick geany.org> writes:
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 fun(T)(Module!"std.stdio".File input, T value) if
 (Module!"std.traits".isIntegral!T)
 {...}
 ```

 I see it as a clear improvment in readability (see original 
 post for details along with shortcomings of `from!` approach )
I really think allowing `with (module_!"std.foo")` before declarations is a better solution from a DRY perspective, plus it works for UFCS. This is a more general change that has other benefits that apply to any static aggregate e.g. enum names - `with(Enum)`, not just imports.
Feb 15
parent reply timotheecour <timothee.cour2 gmail.com> writes:
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 
 (std.traits::isIntegral!T)
 {...}
 ```

 instead of:

 ```
 void fun(T)(Module!"std.stdio".File input, T value) if
 (Module!"std.traits".isIntegral!T)
 {...}
 ```

 I see it as a clear improvment in readability (see original 
 post for details along with shortcomings of `from!` approach )
I really think allowing `with (module_!"std.foo")` before declarations is a better solution from a DRY perspective, plus it works for UFCS. This is a more general change that has other benefits that apply to any static aggregate e.g. enum names - `with(Enum)`, not just imports.
both are useful: * std.stdio::File is nice for 1-off symbols only used 1 or a few times; simple syntax and doesn't add indentation / nesting * 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
Feb 16
parent reply Nick Treleaven <nick geany.org> writes:
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, std.traits") void fun(T)(File input, T value) if (isIntegral!T); with/module_ solves the UFCS member stand-in problem elegantly, how does your proposal solve it?: with (module_!"std.range.primitives") void func(alias pred, R)(R range) if (isInputRange!R && is(typeof(pred(range.front)) == bool); .front has to refer to *either* a member or an imported UFCS function.
Feb 17
parent reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
 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 for now. * when `with` covers multiple declarations, it adds indentation: with(module_!"std.stdio"){ declaration1; declaration2; } * when `with` covers a single one, it doesn't add indentation, but then `::` can be used instead, with arguably simpler syntax: `void fun(T)(std.stdio::File input, T value);` vs `with (module_!"std.stdio") void fun(T)(File input, T value);`
 with/module_ solves the UFCS member stand-in problem elegantly, how does your
proposal solve it?:
 with (module_!"std.range.primitives")
 void func(alias pred, R)(R range)
 if (isInputRange!R && is(typeof(pred(range.front)) == bool);

 .front has to refer to *either* a member or an imported UFCS function.
UFCS equally affects the `::` proposal and the `module_!""`-without-`with` proposal. Besides the option of not using UFCS, we can actually use Alias for this, as I've proposed a while ago in http://forum.dlang.org/post/mailman.1002.1370829729.13711.digitalmars-d-learn puremagic.com: `with (module_!"std.range.primitives") ... pred(range.front)` vs: `... pred(range.Alias!(std.range.primitives::front))` or, if a feature that I've proposed earlier in http://forum.dlang.org/post/mailman.1453.1369099708.4724.digitalmars-d puremagic.com (support UFCS with fully qualified function names) is accepted, it becomes even simpler: `... pred(range.(std.range.primitives::front))` To reiterate what I said earlier: * `foo.bar::symol` is very well suited for the common case of 1-off imports, ie when the import is only needed at a particular location. This is a common case. * If we want to cover multiple declarations, using something like `with (module_!"std.stdio, std.traits")` makes sense and is more DRY.
Feb 18
parent Nick Treleaven <nick geany.org> writes:
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 from!"std.stdio, std.traits"`. But let's assume it can be done for now.
I don't know how to implement it. Possibly with multiple alias this.
 * when `with` covers multiple declarations, it adds indentation:
 with(module_!"std.stdio"){
   declaration1;
   declaration2;
 }

 * when `with` covers a single one, it doesn't add indentation, 
 but then `::` can be used instead, with arguably simpler syntax:

 `void fun(T)(std.stdio::File input, T value);`
 vs
 `with (module_!"std.stdio") void fun(T)(File input, T value);`
What about when the 2nd argument uses File as well? That's the violation of DRY I meant.
 with/module_ solves the UFCS member stand-in problem 
 elegantly, how does your proposal solve it?:
 with (module_!"std.range.primitives")
 void func(alias pred, R)(R range)
 if (isInputRange!R && is(typeof(pred(range.front)) == bool);

 .front has to refer to *either* a member or an imported UFCS 
 function.
UFCS equally affects the `::` proposal and the `module_!""`-without-`with` proposal. Besides the option of not using UFCS, we can actually use Alias for this, as I've proposed a while ago in http://forum.dlang.org/post/mailman.1002.1370829729.13711.digitalmars-d-learn puremagic.com: `with (module_!"std.range.primitives") ... pred(range.front)` vs: `... pred(range.Alias!(std.range.primitives::front))` or, if a feature that I've proposed earlier in http://forum.dlang.org/post/mailman.1453.1369099708.4724.digitalmars-d puremagic.com (support UFCS with fully qualified function names) is accepted, it becomes even simpler: `... pred(range.(std.range.primitives::front))`
No, then front only refers to the std.range one, not R.front if it exists. The with() solution is like a lazy scoped import, affecting overloading, whereas using just from! or mod:: forces a lookup in that module scope only.
Feb 21
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Please fix your newsreader so it submits postings in text format, not html.
Feb 15
prev sibling next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
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 => time to hack D!) template every(T...) { template satisfies(U...) { enum satisfies = { foreach(t; T) foreach(u; U) if(!u!t) return false; return true; }(); } }
That looks pretty neat. Can you find 4-5 cases in which this could be used gainfully in Phobos? Thanks! -- Andrei
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 to then make a new symbol, with a new name, to pass to e.g. allSatisfy. That annoys me, so I've been wanting this sort of thing for a while (which would also make `every` way better to use, instead of having to make a name for every predicate: You know how we have named parameterised enums and aliases? enum isInt(a) = is(a == int); and alias sizeof(a) = a.sizeof; why not allow *anonymous* parameterised enums and aliases, like this: enum areAllInt(TL ...) = allSatisfy!(enum(a) => is(a == int), TL); void foo(TL...)(TL args) if (allSatisfy!(enum(T) => T.sizeof <= 4, TL)) { // ... } an example from phobos: bool ordered(alias less = "a < b", T...)(T values) if (T.length == 2 && is(typeof(binaryFun!less(values[1], values[0])) : bool) || T.length > 2 && is(typeof(ordered!less(values[0..1 + $ / 2]))) && is(typeof(ordered!less(values[$ / 2..$])))) becomes this: bool ordered(alias less = "a < b", T...)(T values) if (T.length > 2 && allSatisfy!(enum(size_t i) => is(typeof(binaryFun!less(values[i], values[i+1])) : bool), Iota!(T.length - 1)) I admit it's not a huge win, but hiding the log_2(N) template depth behind allSatisfy is great: you shouldn't have to (and people wont) think about that when writing a template constraint like this. There is a part of me that thinks all this meta-template stuff is madness though and that modifications to ctfe could make it mostly obsolete, but that's a story for later...
Feb 15
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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 to then
 make a new symbol, with a new name, to pass to e.g. allSatisfy. That
 annoys me, so I've been wanting this sort of thing for a while (which
 would also make `every` way better to use, instead of having to make a
 name for every predicate:

 You know how we have named parameterised enums and aliases?
 enum isInt(a) = is(a == int);
 and
 alias sizeof(a) = a.sizeof;

 why not allow *anonymous* parameterised enums and aliases, like this:

 enum areAllInt(TL ...) = allSatisfy!(enum(a) => is(a == int), TL);

 void foo(TL...)(TL args)
 if (allSatisfy!(enum(T) => T.sizeof <= 4, TL))
 {
     // ...
 }
I've been thinking something similar. But this is the way I see it: A lambda is an anonymous template function which is not yet instantiated. But with the lambda syntax only one the different template parameters are allowed. Why not generalize the lambda syntax to allow different kind of template parameters. Example: What we have today: [1, 2, 3].map!(e => e * 2); Is basically the same as: T __anonymous(T)(T e) { return e * 2; } [1, 2, 3].map!(__anonymous!(int)); But today we cannot represent the following template with a lambda: size_t sizeof(alias a)() { return a.sizeof; } So why not allow this lambda syntax: alias sizeof = (alias a) => a.sizeof; It would be nice if we could reuse the existing syntax for regular template parameters as well: alias isInt = t => is(t == int); auto b = isInt!(int); If the above is not possible, we could add an additional parameter list to lambdas: alias isInt = (t)() => is(t == int); -- /Jacob Carlborg
Feb 15
parent ZombineDev <petar.p.kirov gmail.com> writes:
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 work so
 well for introspecting multiple types at once: normally you 
 have to then
 make a new symbol, with a new name, to pass to e.g. 
 allSatisfy. That
 annoys me, so I've been wanting this sort of thing for a while 
 (which
 would also make `every` way better to use, instead of having 
 to make a
 name for every predicate:

 You know how we have named parameterised enums and aliases?
 enum isInt(a) = is(a == int);
 and
 alias sizeof(a) = a.sizeof;

 why not allow *anonymous* parameterised enums and aliases, 
 like this:

 enum areAllInt(TL ...) = allSatisfy!(enum(a) => is(a == int), 
 TL);

 void foo(TL...)(TL args)
 if (allSatisfy!(enum(T) => T.sizeof <= 4, TL))
 {
     // ...
 }
I've been thinking something similar. But this is the way I see it: A lambda is an anonymous template function which is not yet instantiated. But with the lambda syntax only one the different template parameters are allowed. Why not generalize the lambda syntax to allow different kind of template parameters. Example: What we have today: [1, 2, 3].map!(e => e * 2); Is basically the same as: T __anonymous(T)(T e) { return e * 2; } [1, 2, 3].map!(__anonymous!(int)); But today we cannot represent the following template with a lambda: size_t sizeof(alias a)() { return a.sizeof; } So why not allow this lambda syntax: alias sizeof = (alias a) => a.sizeof; It would be nice if we could reuse the existing syntax for regular template parameters as well: alias isInt = t => is(t == int); auto b = isInt!(int); If the above is not possible, we could add an additional parameter list to lambdas: alias isInt = (t)() => is(t == int);
You can sort of do this even today. All you need is struct with template-ed opCall. See https://github.com/ZombineDev/rxd/blob/v0.0.3/source/rxd/meta2/lambda.d#L12 and https://github.com/ZombineDev/rxd/blob/v0.0.3/source/rxd/xf/xform.d#L54 This one of the few (only?) places that C++14 is better than D, because in C++14 polymorphic lamdas are first-class values, whereas in D alias function literals are templates (i.e. you can refer to them only by alias, can't assign them to enum or auto constants / variables).
Feb 16
prev sibling parent ZombineDev <petar.p.kirov gmail.com> writes:
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 satisfies(U...)
     {
         enum satisfies = true;
     }
 }
(lunch-break => time to hack D!) template every(T...) { template satisfies(U...) { enum satisfies = { foreach(t; T) foreach(u; U) if(!u!t) return false; return true; }(); } }
That looks pretty neat. Can you find 4-5 cases in which this could be used gainfully in Phobos? Thanks! -- Andrei
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 to then make a new symbol, with a new name, to pass to e.g. allSatisfy. That annoys me, so I've been wanting this sort of thing for a while (which would also make `every` way better to use, instead of having to make a name for every predicate: You know how we have named parameterised enums and aliases? enum isInt(a) = is(a == int); and alias sizeof(a) = a.sizeof; why not allow *anonymous* parameterised enums and aliases, like this: enum areAllInt(TL ...) = allSatisfy!(enum(a) => is(a == int), TL); void foo(TL...)(TL args) if (allSatisfy!(enum(T) => T.sizeof <= 4, TL)) { // ... } [snip]
I have a library that allows just that, but with even shorter syntax :P https://github.com/ZombineDev/rxd/blob/v0.0.3/source/rxd/xf/xform.d#L50 https://github.com/ZombineDev/rxd/blob/v0.0.3/source/rxd/meta2/type.d#L241 Though I have feeling that it will make uplinkCoder cringe, because of the pressure it is probably putting on the compiler :D
Feb 16
prev sibling parent Daniel Nielsen <daniel.nielsen.se gmail.com> writes:
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 => time to hack D!) template every(T...) { template satisfies(U...) { enum satisfies = { foreach(t; T) foreach(u; U) if(!u!t) return false; return true; }(); } }
That looks pretty neat. Can you find 4-5 cases in which this could be used gainfully in Phobos? Thanks! -- Andrei
Thanks, I'll get back to you. Unfortunately I just contracted fever, not fit to leave bed. Nothing dangerous, just am K.O.
Feb 16
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
On Wed, 15 Feb 2017 05:28:11 +0000, 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!
Feb 15
prev sibling parent Dominikus Dittes Scherkl <Dominikus.Scherkl continental-corporation.com> writes:
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 body under `static if`, as the user need not be 
 concerned with them.

 This is a general issue in Phobos that too many constraints are 
 user-facing when they don't need to be.
This! Getting rid of overloads and at the same time simplify the constraints by moving them in the function with static if! That would really improve the function signatures!
Feb 15
prev sibling next sibling parent reply Lurker <lurker gmail.com> writes:
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
     && Offset.length >= 1);
Range remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset) if CanRemove!(s, range, offset);
 The function name is on the first line. I think 10 seconds 
 would be an exaggeration of an admittedly real issue.
Thought so, too, but then I *did* spend 10 seconds trying to find it myself!
 Tuple!(InputRange1, InputRange2)
 swapRanges(InputRange1, InputRange2)(InputRange1 r1, 
 InputRange2 r2)
 if (isInputRange!(InputRange1) && isInputRange!(InputRange2)
     && hasSwappableElements!(InputRange1)
     && hasSwappableElements!(InputRange2)
     && is(ElementType!(InputRange1) == 
 ElementType!(InputRange2)));
Tuple!(InputRange1, InputRange2) swapRanges(InputRange1, InputRange2)(InputRange1 r1, InputRange2 r2) if CanSwapRanges!(InputRange1, InputRange2);
Feb 14
parent Chris Wright <dhasenan gmail.com> writes:
On Tue, 14 Feb 2017 21:33:00 +0000, 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
     && isBidirectionalRange!Range && hasLvalueElements!Range &&
     hasLength!Range && Offset.length >= 1);
Range remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset) if CanRemove!(s, range, offset);
Which adds another layer to determine what sort of arguments the thing requires. Fewer layers is better. In the past, I tried to track down compilation errors in Phobos (due to my changes) relating to, I think, template overload selection in std.conv based on template constraints. It was hell. Multiple layers with `static if (__traits(compiles))` interspersed. I'm not too keen on template constraints in general. If you need them, keep them short and keep the entire definition in one place.
 The function name is on the first line. I think 10 seconds would be an
 exaggeration of an admittedly real issue.
Thought so, too, but then I *did* spend 10 seconds trying to find it myself!
Does your editor not have syntax highlighting? For me, I just look immediately below the giant block of blue comment text and check the second word in the line below.
Feb 14
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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 possible.)
It would obviously take a while for me to figure that out. Is not like I have a fully defined new language feature in my head. 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) Why isn't it possible to use "auto" when declaring a parameter with a default argument? Range remove (auto s = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset) A minor improvement, but I also feel like it would lift an arbitrary limitation in the language. Alternatively something that Swift supports: Range remove (SwapStrategy s = .stable, Range, Offset...) (Range range, Offset offset) The compiler knows that the type of "s" is SwapStrategy, therefore "stable" has to be a member of SwapStrategy. In the case of D, the leading dot has a different meaning so another syntax would be required. Unfortunately this has already been discussed and rejected by Walter.
 Before long there is an explosion in
 names ("BidirectionalWithLvalueElementsAndLength", ...). This is what
 has buried not one, but two concepts proposals for C++, leading to the
 current Concepts Lite proposal.
I don't see that as a problem, but I would rather name it "Removable" or something that does not include all the conditions in the name. But I imagine that a constraint would consist of a combination of declarations (like an interface) and boolean conditions. Lets look it differently. For a regular (non-template) function with a user defined type (class, struct). If it was possible to define the type inline, would you? I hope that answer is no. Example: Standard D: struct Bar { int a; int b; } void foo(Bar bar); With inline user defined types: void foo(struct { int a; int b; } bar); Assuming the answer is no, why would it be any different for a template type? You can see all the template constraints for a type as a form of metatype.
 I haven't followed that lately but I
 remember it combines an engineering effort to reduce the number of names
 introduced (for the standard library only, which is a limitation) with
 adding support to Boolean logic (surprise, surprise) to the feature (see
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4377.pdf), the
 most recent proposal, which was rejected for C++17. Over time, C++
 concepts have moved from the broken combinatorially-bankrupt form slowly
 toward D's Boolean constraints (just with a gratuitously awkward
 notation). I presume they will be merged into the language when they'll
 have capabilities comparable to D's system.

 The question is, given this experience, do we want to move the opposite
 direction?
I haven't followed the C++ concepts lately either and not very closely at all so I don't feel I can comment on the C++ concepts. But if I recall correctly, you're "static if" proposal wasn't well received [1]. But now with "if constexpr" it looks like they're changing their minds. [1] "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 -- /Jacob Carlborg
Feb 15
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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)

 Why isn't it possible to use "auto" when declaring a parameter with a
 default argument?

 Range remove
 (auto s = SwapStrategy.stable, Range, Offset...)
 (Range range, Offset offset)

 A minor improvement, but I also feel like it would lift an arbitrary
 limitation in the language.
That's nice, could you please submit as an enhancement request on bugzilla?
 I haven't followed the C++ concepts lately either and not very closely
 at all so I don't feel I can comment on the C++ concepts.
You may want to correct that if you want to make a serious proposal for D concepts.
 But if I
 recall correctly, you're "static if" proposal wasn't well received [1].
 But now with "if constexpr" it looks like they're changing their minds.

 [1] "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 made a terrible mistake" is spelled http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0128r0.html here. It still has a cargo cult flavor because it introduces a new scope, which kinda misses the point of static if. Andrei
Feb 15
next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
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 scope means that code duplication inside of a function is now a must. At that point you might as well just make what you were going to put in the other static if branch as a different overload. It also means design by introspection/range composition is now impossible.
Feb 15
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 15
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 15
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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?
https://issues.dlang.org/show_bug.cgi?id=17186
Thanks. I'll take it up to Walter for preapproval. -- Andrei
It's one of those features that I was surprised when you couldn't do it. - Jonathan M Davis
Feb 15
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 enhancement request on
 bugzilla?
https://issues.dlang.org/show_bug.cgi?id=17186
Thanks. I'll take it up to Walter for preapproval. -- Andrei
It's one of those features that I was surprised when you couldn't do it.
We agree. It's preapproved now. -- Andrei
Feb 15
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 15
parent reply ZombineDev <petar.p.kirov gmail.com> writes:
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 generalizing this feature to allow introducing template value parameters without default value, i.e.: // Note: `beg` and `end` have no default value auto bounded (auto beg, auto end, auto onErrPolicy = Enforce("Value out of range"), T) (T value) { return Bounded!(beg, end, Policy)(value); } struct Enforce { this(string) { /* */ } } int tmp; readf("%s", &x); enum policy = Enforce("User age must be between 18 and 150"); auto userAge = bounded!(18, 150, policy)(tmp); "Declaring non-type template arguments with auto" is also coming to C++17: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0127r1.html 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?
Feb 15
next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
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. We just never thought of it.
What do you think about generalizing this feature to allow introducing template value parameters without default value, i.e.: // Note: `beg` and `end` have no default value auto bounded (auto beg, auto end, auto onErrPolicy = Enforce("Value out of range"), T) (T value) { return Bounded!(beg, end, Policy)(value); }
note that this would still be usable with constraits via e.g. if(is(typeof(beg) : int))
Feb 15
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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. Question though, what happens with an array literal, example: void foo(int[] a = [1, 2, 3])() { auto b = a; // allocation ? auto c = a; // allocation ? } As far as I understand, if an array is declared as a manifest constant it will cause a new allocation for each time it's used. enum a = [1, 2, 3]; auto b = a; // new allocation auto c = a; // new allocation What happens when an array literal is a default value for a template parameter? -- /Jacob Carlborg
Feb 15
parent ZombineDev <petar.p.kirov gmail.com> writes:
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 it's not possible to change the parameter inside the function anyway. Question though, what happens with an array literal, example: void foo(int[] a = [1, 2, 3])() { auto b = a; // allocation ? auto c = a; // allocation ? } As far as I understand, if an array is declared as a manifest constant it will cause a new allocation for each time it's used. enum a = [1, 2, 3]; auto b = a; // new allocation auto c = a; // new allocation What happens when an array literal is a default value for a template parameter?
enums are just literals - values without identity. This means that if you need them at runtime, the compiler will need to allocate storage for each time they are used. In cases where such a values is used in more places, it may be more economical to assign it to a static immutable variable and reference it in place of the enum. In the case of template parameters I would expect this to be even more true, because an array by definition is a contiguous chunk of memory and a template parameter is something encoded in the mangled name of the symbol at runtime, so the compiler can't get away from allocating additional storage for each usage of the template value parameter at runtime. ( compiler devs, please correct me if I am wrong)
Feb 16
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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 for the C++ people here. Looks like someone didn't explain the benefits/uses of static if very well. It also looks like they failed to point to Phobos as an example of great static if usage. I imagine many heads would explode after seeing Andrei's `find` improvements with static if.
Feb 15
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 language"
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf
I honestly feel bad for the C++ people here. Looks like someone didn't explain the benefits/uses of static if very well. It also looks like they failed to point to Phobos as an example of great static if usage. I imagine many heads would explode after seeing Andrei's `find` improvements with static if.
LOL. It would be interesting to know which parts of D or Phobos blew people's minds. Personally, startsWith blew my mind. I remember taking up the challenge of making endsWith work with all of the same kind of arguments that startsWith did, and at the time, I had no idea how startsWith was implemented. Seeing how it used recursive template instantiations definitely took a bit to wrap my mind around and was _very_ eye opening. - Jonathan M Davis
Feb 15
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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 possible.) Before long there is an explosion in
 names ("BidirectionalWithLvalueElementsAndLength", ...).
Forgot to say that I don't think it's unreasonable to have a named constraint for each function (regardless if using only existing language features or adding something new). That way you can lift out the constraint separately from the function declaration. One way to make something complex less complex, is to split it up. It's not like you would have the complete source code of an application in a single file, that would be too much to read in one place (yes, there are other reasons to have multiple files). Same idea here. -- /Jacob Carlborg
Feb 15
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
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.
Copying here to make things easier: 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); The function name is on the first line. I think 10 seconds would be an exaggeration of an admittedly real issue.
 Example [2], 5 lines.
Copying here as well (reflowed for email): Tuple!(InputRange1, InputRange2) swapRanges(InputRange1, InputRange2)(InputRange1 r1, InputRange2 r2) if (isInputRange!(InputRange1) && isInputRange!(InputRange2) && hasSwappableElements!(InputRange1) && hasSwappableElements!(InputRange2) && is(ElementType!(InputRange1) == ElementType!(InputRange2))); One immediate matter here is redundant parens, of which elimination would lead to the marginally more palatable: Tuple!(InputRange1, InputRange2) swapRanges(InputRange1, InputRange2)(InputRange1 r1, InputRange2 r2) if (isInputRange!InputRange1 && isInputRange!InputRange2 && hasSwappableElements!InputRange1 && hasSwappableElements!InputRange2 && is(ElementType!InputRange1 == ElementType!InputRange2));
 and what steps can we take to improve them. Could you
 please give a few examples on how to do things better? Thx! 
 -- Andrei
Well, I would prefer to have template constraints as its own entity in the language not not just a bunch of boolean conditions. This has been talked about before several times. Something like: constraint Foo { void foo(); } void bar(T : Foo)(T t);
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 possible.) Before long there is an explosion in names ("BidirectionalWithLvalueElementsAndLength", ...).
If I had my way, like so: Tuple!(InputRange1, InputRange2) swapRanges (InputRange1: (InputRange, HasSwappableElements), InputRange2: (InputRange, HasSwappableElements)) (InputRange1 r1, InputRange2 r2) if (is(ElementType!(InputRange1) == ElementType!(InputRange2))); Assuming I'm still having my way, the above would result in the compiler telling me that given: struct Foo { enum empty = false; enum front = 42; } If I tried to instantiate swapRanges!(Foo, Foo), I'd want to get something akin to: error: foo.Foo does not satisfy InputRange: no function `popFront` for `foo.Foo` For now I'm getting quite a bit of mileage from my concepts library. Atila
Feb 15
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
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.
Feb 14
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 examples on how to do things better? Thx! -- Andrei
Unfortunately, I'm not sure that there's much that we can do. Each of the features that clutter up a function signature is useful and valuable in and of itself, but when you add them all together, it can get pretty messy. We've managed to improve some aspects over time, but there has to be a limit to it. At some point, the information takes up however much space it takes up. Having auto functions helped considerably for cleaning up function signatures where templates were involved. Declaring eponymous templates to use as traits for commonly used idioms helps - and in some cases, maybe we should add more of those for common combinations, but the best we could do is clean up some common cases, because it ultimately doesn't scale well for the reasons that you explained why C++ has had issue with getting concepts into the standard. Having different defaults for function attributes would help in some cases (e.g. have safe and pure be the default), but I don't see how we could do that at this point without breaking a bunch of code. And attribute inference already takes care of the attributes on the most cluttered functions, since those are going to be templated functions with template constraints. I think that things just reach a point where if you want the functionality, you get a messy function signature, and you can't do much more than try and format it nicely. For better or worse, it's just one of the costs of what D provides. 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 1005 and the proposed from template, I also think that it's taking it too far. IMHO, it's just not worth marking functions even further - at least not in most code. Maybe it's worth it in something like Phobos where everyone is using it and benefiting from the compilation speed up, but Walter has been wanting to implement lazy imports anyway, and that would fix the problem without doing anything to any function signatures. It does lose the benefits of tying the imports to the function, but personally, I don't think that that's's worth the extra cost of further cluttering up the function signature. As it is, I'm increasingly of the opinion that local and selective imports aren't worth it. It's just so much nicer to able to slap the required imports at the beginning of the module and forget about them than having to worry about maintaining a list of selective imports or have all of the extra import lines inside of all of the functions. And adding imports to the function signatures is just making the whole local import situation that much worse. So, regardless of what happens with DIP 1005 or from, I'd very much like to see lazy imports implemented, and I don't expect use DIP 1005 or from in much code that I write. - Jonathan M Davis
Feb 14
parent kinke <noone nowhere.com> writes:
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 1005 and the proposed 
 from template, I also think that it's taking it too far. IMHO, 
 it's just not worth marking functions even further - at least 
 not in most code. Maybe it's worth it in something like Phobos 
 where everyone is using it and benefiting from the compilation 
 speed up, but Walter has been wanting to implement lazy imports 
 anyway, and that would fix the problem without doing anything 
 to any function signatures. It does lose the benefits of tying 
 the imports to the function, but personally, I don't think that 
 that's's worth the extra cost of further cluttering up the 
 function signature. As it is, I'm increasingly of the opinion 
 that local and selective imports aren't worth it. It's just so 
 much nicer to able to slap the required imports at the 
 beginning of the module and forget about them than having to 
 worry about maintaining a list of selective imports or have all 
 of the extra import lines inside of all of the functions. And 
 adding imports to the function signatures is just making the 
 whole local import situation that much worse.
+1. D's beautiful syntax plays a key role for attracting new folks, and I see it endangered by recent developments.
Feb 14
prev sibling parent Jack Stouffer <jack jackstouffer.com> writes:
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.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md#alternative-lazy-imports
Feb 14
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Mon, 13 Feb 2017 19:49:28 -0800
schrieb Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com>:

 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) {...}
 ```
If you use a single ':' instead you can argue it's simply a shortened, inline version of a selective import: import std.stdio : File; //still valid D import std.stdio:File; //expression instead of statement => remove ; import std.stdio:File //We're not importing a symbol, we're simply referring to it std.stdio:File -- Johannes
Feb 14
next sibling parent reply Daniel N <no public.email> writes:
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 
 <digitalmars-d puremagic.com>:

 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) {...}
 ```
If you use a single ':' instead you can argue it's simply a shortened, inline version of a selective import: import std.stdio : File; //still valid D import std.stdio:File; //expression instead of statement => remove ; import std.stdio:File //We're not importing a symbol, we're simply referring to it std.stdio:File -- Johannes
my_module:File is it a label followed by File or File inside my_module?
Feb 14
next sibling parent Daniel N <no public.email> writes:
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
Feb 14
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 14 Feb 2017 10:23:51 +0000
schrieb Daniel N <no public.email>:

 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 
 <digitalmars-d puremagic.com>:
  
 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) {...}
 ```  
If you use a single ':' instead you can argue it's simply a shortened, inline version of a selective import: import std.stdio : File; //still valid D import std.stdio:File; //expression instead of statement => remove ; import std.stdio:File //We're not importing a symbol, we're simply referring to it std.stdio:File -- Johannes
my_module:File is it a label followed by File or File inside my_module?
This might be a problem. Labels can only occur in front of a statement though: https://dlang.org/spec/statement.html#LabeledStatement So it boils down to: ModuleFullyQualifiedName:ImportBind vs LabeledStatement -- Johannes
Feb 14
prev sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 <digitalmars-d puremagic.com>:

 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) {...}
 ```
If you use a single ':' instead you can argue it's simply a shortened, inline version of a selective import: import std.stdio : File; //still valid D import std.stdio:File; //expression instead of statement => remove ; import std.stdio:File //We're not importing a symbol, we're simply referring to it std.stdio:File -- Johannes
Exactly! I was going to write the same
Feb 14