Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2017-02-16 01:40, John Colvin wrote:
Slightly OT, but it is related so bear with me:
Design by introspection is great and prevent having to make new names
for every possible combo of features. Unfortunately, it doesn't work so
well for introspecting multiple types at once: normally you have 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
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2017-02-16 01:37, ZombineDev wrote:
BTW, shouldn't we use `enum`, instead of `auto`, since everywhere else
`enum` means guaranteed to be computed at compile-time whereas `auto`
means the opposite?
Far enough, since it's not possible to change the parameter inside the
function anyway.
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
Re: .byKeyValue should probably return a Tuple
On Thu, Feb 16, 2017 at 05:02:41AM +, Yuxuan Shui via Digitalmars-d wrote:
> On Wednesday, 15 February 2017 at 22:02:01 UTC, Seb wrote:
> > On Wednesday, 15 February 2017 at 21:54:20 UTC, Yuxuan Shui wrote:
> > > for(k, v; aa) { ... } is better than:
> > >
> > > for(o; aa) {
> > > auto k = o.key, v = o.value;
> > > ...
> > > }
> > >
> > > right?
> > >
> > > Are there any reason why .byKeyValue doesn't return a Tuple?
> >
> > There's byPair (http://dlang.org/phobos/std_array.html#byPair) that as a
> > library does exactly the following:
> >
> > ```
> > a.byKeyValue.map!(pair => tuple(pair.key, pair.value))
> > ```
>
> Thanks!
>
> It should be more visible though. Can we include it here:
> https://dlang.org/spec/hash-map.html ?
Please file a bug against dlang.org to request this doc update, so that
people won't forget to do it. Thanks!
T
--
It's amazing how careful choice of punctuation can leave you hanging:
Re: D future ...
Jack Stouffer wrote: Can you please make a bug with a level of regression for your specific problem? yeah. https://issues.dlang.org/show_bug.cgi?id=17188
Re: .byKeyValue should probably return a Tuple
On Wednesday, 15 February 2017 at 22:02:01 UTC, Seb wrote:
On Wednesday, 15 February 2017 at 21:54:20 UTC, Yuxuan Shui
wrote:
for(k, v; aa) { ... } is better than:
for(o; aa) {
auto k = o.key, v = o.value;
...
}
right?
Are there any reason why .byKeyValue doesn't return a Tuple?
There's byPair (http://dlang.org/phobos/std_array.html#byPair)
that as a library does exactly the following:
```
a.byKeyValue.map!(pair => tuple(pair.key, pair.value))
```
Thanks!
It should be more visible though. Can we include it here:
https://dlang.org/spec/hash-map.html ?
Re: D future ...
On Thursday, 16 February 2017 at 03:46:29 UTC, ketmar wrote: you want the example? `scope` was added to `_compare_fp_t`from "core.stdc.stdlib". thank you for breaking ALL my code thatis using `qsort()`. i guess nobody from core dev team really used`qsort()` from libc, so it is ok to break the code with it. Yes, I'm really disappointed with the way that DIP1000 is turning out. It was explicitly stated that nothing would be broken right away and that everything would be given a deprecation cycle. Can you please make a bug with a level of regression for your specific problem?
Re: D future ...
Jack Stouffer wrote: And I sincerely hope they work to fix them before adding in a bunch of new DIPs which will further complicate matters, especially with regard to function signitures. so far i see that they just like to say: "we won't break user's code", and then silently breaking it, even without deprecation stage. thank you, guys; guessing when "we won't break the code" really means something is a fun game. you want the example? `scope` was added to `_compare_fp_t` from "core.stdc.stdlib". thank you for breaking ALL my code that is using `qsort()`. i guess nobody from core dev team really used `qsort()` from libc, so it is ok to break the code with it. yeah, this was done in git, not in release. but still. btw, for a short time compiler was unable to build itself at all, with all that "scope spam". i.e. nobody really cares about travis, or travis cannot properly check commits and is useless (or how else patch that did broke travis builds lands in "master"?) what i really want to say is that spamming code with shiny new stuff is done... too fast, and tends to disregard "we won't break users' code" mantra. sure, adding new features is fun, i know it, and i like to do it too. but please, let's do it consistently! either drop "we won't break" and start *really* adding features, or stop adding random half-finished things to compiler/druntime/phobos. at least in "master". p.s.: please, no "don't use git HEAD" blah-blah. it is not about short breakages (which is normal with "bleeding edge"). it is all about lack of consistency and proper... practices. maybe even proper project vision. p.p.s.: "mostly volunteers", "free", etc. i know. thank you all for your hard work. i appreciate it, and that's exactly why i don't want it to be spoiled by seemingly small and insignificant things.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Thursday, 16 February 2017 at 00:37:00 UTC, ZombineDev wrote:
On Thursday, 16 February 2017 at 00:08:12 UTC, Walter Bright
wrote:
On 2/15/2017 12:31 PM, Jonathan M Davis via Digitalmars-d
wrote:
It's one of those features that I was surprised when you
couldn't do it.
It was an oversight. 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))
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 19:39:52 UTC, Andrei
Alexandrescu wrote:
On 02/15/2017 06:20 AM, Daniel N wrote:
On Wednesday, 15 February 2017 at 09:22:14 UTC, Daniel N wrote:
template every(T...)
{
template satisfies(U...)
{
enum satisfies = true;
}
}
(lunch-break => 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...
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Thursday, 16 February 2017 at 00:08:12 UTC, Walter Bright
wrote:
On 2/15/2017 12:31 PM, Jonathan M Davis via Digitalmars-d wrote:
It's one of those features that I was surprised when you
couldn't do it.
It was an oversight. We just never thought of it.
What do you think about 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?
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2/15/2017 12:31 PM, Jonathan M Davis via Digitalmars-d wrote: It's one of those features that I was surprised when you couldn't do it. It was an oversight. We just never thought of it.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
Also, as mentioned in the std.algorithm.mutation.remove case, constraints in Phobos often confuse "requirements" with "specializations". Requirements should be user-facing constraints, while specializations are implementation details better handled with internal static if.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2/15/2017 1:24 PM, Jonathan M Davis via Digitalmars-d wrote: So, regardless of the exact terminology, we have a whole set of very similar but subtly different traits. And as it stands, they _will_ get screwed up unless someone is carefully looking at each to make sure that they actually use 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.
Re: D future ...
On Wednesday, 15 February 2017 at 21:46:32 UTC, bpr wrote: You're missing what I consider to be 'the Big Picture', namely that Swift will become popular on non-Apple platforms, and it needs to be fairly capable to compete with Go, Java, and C++, and others. IBM is already backing server side Swift to some degree. I don't know if that will happen anytime soon. I think the functionality that the original creator has suggested for system-level programming has to be in place first. Currently the language/runtime is geared towards best practices inherited from Foundation/Objective-C/Cocoa/macOS... Which makes sense, but makes Swift a second rate citizen in other environments.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 02/15/2017 03:31 PM, Jonathan M Davis via Digitalmars-d wrote: On Wednesday, February 15, 2017 14:30:02 Andrei Alexandrescu via Digitalmars-d wrote: On 02/15/2017 02:22 PM, Jacob Carlborg wrote: On 2017-02-15 15:01, Andrei Alexandrescu wrote: That's nice, could you please submit as an 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
Re: .byKeyValue should probably return a Tuple
On Wednesday, 15 February 2017 at 21:54:20 UTC, Yuxuan Shui wrote:
for(k, v; aa) { ... } is better than:
for(o; aa) {
auto k = o.key, v = o.value;
...
}
right?
Are there any reason why .byKeyValue doesn't return a Tuple?
There's byPair (http://dlang.org/phobos/std_array.html#byPair)
that as a library does exactly the following:
```
a.byKeyValue.map!(pair => tuple(pair.key, pair.value))
```
.byKeyValue should probably return a Tuple
for(k, v; aa) { ... } is better than:
for(o; aa) {
auto k = o.key, v = o.value;
...
}
right?
Are there any reason why .byKeyValue doesn't return a Tuple?
Re: D future ...
On Wednesday, 15 February 2017 at 21:16:51 UTC, Meta wrote: Isn't that a little uncharitable? I just spent about 20 minutes list out all of my problems with the language, and how somethings are pretty broken. But I deleted it and I'm not going to post it. It was just another rant. One that doesn't change anything. All I'll say is the current language maintainers know what's broken. And I sincerely hope they work to fix them before adding in a bunch of new DIPs which will further complicate matters, especially with regard to function signitures.
Re: D future ...
On Wednesday, 15 February 2017 at 17:53:43 UTC, Ola Fosheim Grøstad wrote: Typo: I mean't that one cannot assume that Apple hardware has more than 2 cores (so one has to write applications that perform well with only 2 cores). You're missing what I consider to be 'the Big Picture', namely that Swift will become popular on non-Apple platforms, and it needs to be fairly capable to compete with Go, Java, and C++, and others. IBM is already backing server side Swift to some degree.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wed, Feb 15, 2017 at 09:03:46PM +, Jack Stouffer via Digitalmars-d wrote: > On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright wrote: > > I'd like to take a step back and devise a consistent taxonomy of these > > things > > Ok > > > 1. auto decoding dynamic arrays > > Narrow 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.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2/15/2017 1:03 PM, Jack Stouffer wrote: On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright wrote: I'd like to take a step back and devise a consistent taxonomy of these things Ok 1. auto decoding dynamic arrays Narrow strings 2. not auto decoding arrays Wide strings 3. 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.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, February 15, 2017 21:03:46 Jack Stouffer via Digitalmars-d
wrote:
> On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright
>
> wrote:
> > I'd like to take a step back and devise a consistent taxonomy
> > of these things
>
> Ok
>
> > 1. auto decoding dynamic arrays
>
> Narrow 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
Re: D future ...
On Wednesday, 15 February 2017 at 20:53:58 UTC, Jack Stouffer wrote: On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote: There's little point in having more features if what's already there is half broken and not well-defined. This is what Manu and deadalnix have been saying for the past three years. Its fallen on deaf ears. Isn't that a little uncharitable?
Re: D future ...
On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote: There's little point in having more features if what's already there is half broken and not well-defined. +1
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright wrote: I'd like to take a step back and devise a consistent taxonomy of these things Ok 1. auto decoding dynamic arrays Narrow strings 2. not auto decoding arrays Wide strings 3. static arrays Do these need to be called 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
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
Please fix your newsreader so it submits postings in text format, not html.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, February 15, 2017 12:54:02 Walter Bright via Digitalmars-d wrote: > On 2/15/2017 10:51 AM, Andrei Alexandrescu wrote: > > isStringLike. I wanted to add this for a while already. Please do! -- > > Andrei > What I've found messy and confusing with string overloads in Phobos is > there 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
Re: D future ...
On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote: There's little point in having more features if what's already there is half broken and not well-defined. This is what Manu and deadalnix have been saying for the past three years. Its fallen on deaf ears.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2/15/2017 10:51 AM, Andrei Alexandrescu wrote: isStringLike. I wanted to add this for a while already. Please do! -- Andrei What I've found messy and confusing with string overloads in Phobos is there are at least 6 kinds of strings: 1. auto decoding dynamic arrays 2. not auto decoding 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.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, February 15, 2017 14:30:02 Andrei Alexandrescu via Digitalmars-d wrote: > On 02/15/2017 02:22 PM, Jacob Carlborg wrote: > > On 2017-02-15 15:01, Andrei Alexandrescu wrote: > >> That's nice, could you please submit as an enhancement request on > >> bugzilla? > > > > 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
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 20:09:46 UTC, Timothee Cour
wrote:
This thread completely diverged from the original post, which
was propsing `::` instead of `from!`:
```
void fun(T)(std.stdio::File input, T value) if
(std.traits::isIntegral!T)
{...}
```
instead of:
```
void 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.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 18:51:40 UTC, Andrei Alexandrescu wrote: On 02/15/2017 12:18 PM, Seb wrote: uint getAttributes(R)(R name) if (isInputRange!R && !isInfinite!R && isSomeChar!(ElementEncodingType!R) && !isConvertibleToString!R); Now as this same block is used > 30x in Phobos 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
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
This thread completely diverged from the original post, which was propsing
`::` instead of `from!`:
```
void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T)
{...}
```
instead of:
```
void fun(T)(Module!"std.stdio".File input, T value) if
(Module!"std.traits".isIntegral!T)
{...}
```
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
>
>
>
Re: D future ...
On Wednesday, 15 February 2017 at 16:07:18 UTC, Ola Fosheim Grøstad wrote: I think Go has benefitted some from having limited and stable language semantics and continuously improving on the implementation. IMO that should make it attractive in the server space, i.e. you get low tooling-related maintenance cost and still get real benefits from recompiling with new versions of the compiler. That is a very good point, I had never considered the consequences of semantics stabilization on tooling. It strenghtens (along with DIP1005) my opinion that D is fine as it is and that no new feature should be added before at least two years, while fixing the implementation should get the focus. It doesn't mean we can't add anything new, better C++ integration or memory management semantics would be fine, as long as it is an already begun project. There's little point in having more features if what's already there is half broken and not well-defined.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 02/15/2017 06:20 AM, Daniel N wrote:
On Wednesday, 15 February 2017 at 09:22:14 UTC, Daniel N wrote:
template every(T...)
{
template satisfies(U...)
{
enum satisfies = true;
}
}
(lunch-break => time to hack D!)
template every(T...)
{
template satisfies(U...)
{
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
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 02/15/2017 02:22 PM, Jacob Carlborg wrote: On 2017-02-15 15:01, Andrei Alexandrescu wrote: That's nice, could you please submit as an enhancement request on bugzilla? https://issues.dlang.org/show_bug.cgi?id=17186 Thanks. I'll take it up to Walter for preapproval. -- Andrei
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2017-02-15 15:01, Andrei Alexandrescu wrote: That's nice, could you please submit as an enhancement request on bugzilla? https://issues.dlang.org/show_bug.cgi?id=17186 -- /Jacob Carlborg
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 02/15/2017 12:18 PM, Seb wrote: uint getAttributes(R)(R name) if (isInputRange!R && !isInfinite!R && isSomeChar!(ElementEncodingType!R) && !isConvertibleToString!R); Now as this same block is used > 30x in Phobos one could argue that it makes sense to use a convenience trait like: isStringLike. I wanted to add this for a while already. Please do! -- Andrei
Re: D future ...
On Wednesday, 15 February 2017 at 17:08:37 UTC, Ola Fosheim Grøstad wrote: modelling paradigm? One cannot really assume that Apple hardware has more than 2 CPUs. Typo: I mean't that one cannot assume that Apple hardware has more than 2 cores (so one has to write applications that perform well with only 2 cores).
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 17:18:15 UTC, Seb wrote: Now as this same block is used > 30x in Phobos That tells me you already have an empirical clear win! If you wrote exactly the same thing 30x inside the functions, you'd move it out to a new function too. if (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.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 16:20:30 UTC, Chris Wright wrote: The greatest annoyance is if I have to read through several files of phobos sources just to figure out why there's no matching overload for this function call that looks right to me. I really really REALLY REALLY wish the 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.)
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 17:10:26 UTC, Adam D. Ruppe wrote: On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote: Your documentation is an improvement but it doesn't help when reading the source code. Yeah, I think there's a few things we can do in the source too. We 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?
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote: Your documentation is an improvement but it doesn't help when reading the source code. Yeah, I think there's a few things we can do in the source too. We should find the common combinations and abstract them out, like I 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.
Re: D future ...
On Wednesday, 15 February 2017 at 16:41:31 UTC, bpr wrote: Swift took over quickly because Apple has mandated it. While I'm happy about that, there's no denying that Swift wouldn't be where it is without the weight of Apple behind it. I'd go as far as to say that Swift's success is assured (unless Apple It may have been assured, but the adoption _rate_ comes from having a good match on semantics and existing practices. Replace Swift with Haskell and the adoption would have been much slower. As a PL, Swift looks nice, but they'll have to come up with a more complete story around concurrency. Do you mean parallell execution (CPU) or concurrency as a modelling paradigm? One cannot really assume that Apple hardware has more than 2 CPUs. So as a starting point you can presume that one core taken by the main UI event loop and the other one taken by real time code. Whatever is left is for Apple's "Operation Queues" (dispatch queues, basically worker threads working in a FIFO manner IIRC). https://developer.apple.com/library/content/documentation/General/Conceptual/ConcurrencyProgrammingGuide/
Re: D future ...
On Wednesday, 15 February 2017 at 16:28:00 UTC, Jacob Carlborg wrote: On 2017-02-15 17:07, Ola Fosheim Grøstad wrote: This trend will continue. Programming for iOS without XCode is unthinkable at this point, and similar situations exists for other platforms. TextMate on macOS is a native macOS application (Cocoa, C++) but does not use Xcode to build, it's using ninja. I guess that's expected, to use TextMate to build TextMate. It certainly is possible to build for macOS/iOS without using XCode, but still unthinkable for most. Even JetBrain's commercial offering fall short because they lag behind when Apple release a new OS version. If the language/framework vendor provides an IDE it becomes difficult to break into the market, if for no other reason than being sure that timeliness requirements are met.
Re: D future ...
On Wednesday, 15 February 2017 at 14:44:55 UTC, Ola Fosheim Grøstad wrote: Another example is Swift. Swift managed to take over Objective-C rather quickly IMO, but Swift has also absorbed the non-C semantics of Objective-C, thus it did not require changing existing practice significantly. Swift took over quickly because Apple has mandated it. While I'm happy about that, there's no denying that Swift wouldn't be where it is without the weight of Apple behind it. I'd go as far as to say that Swift's success is assured (unless Apple drops it, which looks unlikely) and that because Swift has money behind it, more money will follow, and so will a thriving ecosystem, on and off OS X. As a PL, Swift looks nice, but they'll have to come up with a more complete story around concurrency.
Re: D future ...
On 2017-02-15 17:07, Ola Fosheim Grøstad wrote: This trend will continue. Programming for iOS without XCode is unthinkable at this point, and similar situations exists for other platforms. TextMate on macOS is a native macOS application (Cocoa, C++) but does not use Xcode to build, it's using ninja. I guess that's expected, to use TextMate to build TextMate. -- /Jacob Carlborg
Re: extern(C) and mangling type names
On Tue, 14 Feb 2017 20:51:43 -0800, Timothee Cour via Digitalmars-d wrote: Please configure your newsreader to use plain text. It appends HTML garbage to the end of your post.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wed, 15 Feb 2017 08:56:00 +0100, Jacob Carlborg wrote: > Your documentation is an improvement but it doesn't help when reading > the source code. For me, it almost entirely obviates reading the source code. I only need to read it if I'm trying to modify it, at which point I'm already 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.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wed, 15 Feb 2017 05:28:11 +, Adam D. Ruppe wrote: > On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: >> A further improvement in the documentation would be to add links to >> isBidirectionalRange and hasLvalueElements. > > Kneel before your god! We're not worthy!
Re: D future ...
On Wednesday, 15 February 2017 at 10:38:04 UTC, Russel Winder wrote: It is also "re-tribalising" around the Rust, Go, Swift, C++17 for native code; Java 8/9, Kotlin, Scala, Groovy, Clojure on the JVM; ECMAScript, TypeScript, Elm in the browser, and Python in data science and such like. OK not orthogonal dimensions. Yeah, it isn't orthogonal dimensions. Not quite sure what you mean by "re-tribalising". Do you mean that developers have broken up from older languages like C++98 and Objective-C and regrouped over Rust, Go, Swift and C++17? I guess that is a reasonable interpretation. I am still not sure exactly what Rust's demographic is, but I guess it may be catering for those that want a high-level C with a preference for functional programming over templated programming? An interesting perspective is who is putting money into IDEs and JetBrains are a good measuring device for this. C/C++ with CMake got CLion which is now getting a lot of Swift and Rust love. Go got a whole new IDE in Goglang. C#, Ruby, JavaScript get a lot of push, as do the gamut of JVM languages in IDEA – where the Rust plugin gets a lot of push. Python has PyCharm. I haven't seen Gogland before, too bad I turned down the full suite IDE offering from JetBrains recently... VSCode with plugins is ok for Go and TypeScript though. But it is a clear trend that newer languages are more tuned for IDE support, i.e. the language design is made with text-completion support in mind. This is one primary advantage with TypeScript over JavaScript for instance and alone worth the switch. Writing Python code with PyCharm is also quite different from using emacs, it is almost a "different language". This trend will continue. Programming for iOS without XCode is unthinkable at this point, and similar situations exists for other platforms. Emacs, VIM, SublimeText, Atom, etc. get some love but few people really care about them compared to the Eclipse and JetBrains IDEs. The cognitive load is just too high these days to use a regular editor if you want to be productive. The APIs are too big, there are too many of them, and they change too much and frequently to deal with "non-standard" editor issues. Just the automated hinting that something is deprecated and suggestions for replacements are invaluable time savers when upgrading codebases. So if we measure traction by IDE and editor effort D is losing, along with Fantom, Crystal, Pony, Nim, and all the other languages that focus on the language to the expense of the way people use the language. I think IDE support should be part of the core project these days. My impression is that Dart had a lot more enthusiastic following when they provided a Dart-editor (eclipse fork). JetBrains supports Dart, but it isn't really the same thing when it isn't free and directly supported by the language provider. I noticed that the Whiley website says that they are maintaining an eclipse plugin as part of the project. Kingsley started work on the IDEA plugin and Bruno on the Eclipse plugin. Some people are working on the IDEA plugin (I am supposed to be as well, but I am failing). To get D out there with traction, these, not the compiler, should be the core focus of attention – the place where lots of resource is going in. One cannot expect volunteers to keep at it for years. And being left in the dark at some point in the future is not a very enticing prospect when adopting a language. There are currently more open source projects on github than (capable) developers... so one cannot expect others to take over either. It was different back in the day when emacs was the only real alternative. Community driven development seems to no longer work reliably for projects that have high maintenance costs (with notable exceptions). I guess this having something to do with the basic needs being met by the Linux ecosystem (the basic Unix toolset being available). Maslow's hierarchy of needs? Ceylon, Kotlin, Rust, Go have some core resource that attracts more resource, and there is a snowball effect. I think Go has benefitted some from having limited and stable language semantics and continuously improving on the implementation. IMO that should make it attractive in the server space, i.e. you get low tooling-related maintenance cost and still get real benefits from recompiling with new versions of the compiler. I don't much about Rust and snowball effects? I thought Rust had stagnated, but maybe I am wrong? No matter how good D and the compilers are, without high quality IDE support, it will be a peripheral language for the core adherents. But we have been round this time and again, with extraordinarily little progress. The most important factor is the overall composition of the eco system and a good IDE makes it all come together. Kinda like a carpenter's workbench. You can make small scale stuff without, but you wouldn't do
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, February 15, 2017 14:35:40 Jack Stouffer via Digitalmars-d wrote: > On Wednesday, 15 February 2017 at 08:53:30 UTC, Jacob Carlborg > > wrote: > > "The static if feature recently proposed for C++ [1, 2] is > > fundamentally flawed, and its adoption would be a disaster for > > the 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
Re: D future ...
On Wednesday, 15 February 2017 at 11:14:11 UTC, John Colvin wrote: On Tuesday, 14 February 2017 at 10:22:26 UTC, Ola Fosheim Grøstad wrote: But, the way I see it TypeScript + "native libraries" has the potential for covering a lot of ground. The eco system is exploding. Having done a fair amount of professional development in typescript over the last 6 months, I have to say I'm not as excited about it as I used to be. Don't get me wrong, I still think it's the best language in its space, but the javascript underneath it shows through in a lot of bad places and the lack of real meta-programming makes it hard to get your types exactly how you want them. Overall I've found it a frustrating when I compare it to working in D, despite it having a bunch of cool features I'd love to use in D. The structural flow type-system of TypeScript takes time to get used to and it only provides limited static type checks, so it has rather limited generating capabilities (typing is primarily for correctness checks and IDE-text-completion support). The template-expansion area is a field where D is better off, certainly. What MS did right though was to create something that is not too unfamiliar for people that know languages like JavaScript, C#, Java or Swift, yet they absorb trendy frameworks like React and Angular as well as all existing JavaScript libraries. Not having a fixed build system is a weakness, and a bit frustrating, but I guess this is deliberately done to absorb as many developers as possible with their existing preferences. Objectively a competing language like Dart is better, but Dart is different enough to not having the ability to absorb developers. My viewpoint is that this ability to absorb existing practices (like build systems and code bases) is probably where TypeScript is gaining traction from. I think D might be a bit like Dart in this regard. It is closely related to, but yet too different from C/C++ to absorb the existing practices. Another example is Swift. Swift managed to take over Objective-C rather quickly IMO, but Swift has also absorbed the non-C semantics of Objective-C, thus it did not require changing existing practice significantly.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 14:01:28 UTC, Andrei Alexandrescu wrote: It still has a cargo cult flavor because it introduces a new scope, which kinda misses the point of static if. That's an understatement. Having static if introduce a new scope makes static if useless. Creating a new 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.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 08:53:30 UTC, Jacob Carlborg wrote: "The static if feature recently proposed for C++ [1, 2] is fundamentally flawed, and its adoption would be a disaster for the language" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf I honestly feel bad 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.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Tuesday, 14 February 2017 at 22:01:47 UTC, H. S. Teoh wrote: Thankfully, the docs for std.conv.to have been greatly improved since the last time I had to work with the code -- everything is now consolidated under a single template function std.conv.to, and the implementation details are 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
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2/15/17 3:53 AM, Jacob Carlborg wrote: I do see a possibility for a slightly improvement in a different area, in the example of "remove". If we look at the signature, without the constraints: Range remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...) (Range range, Offset offset) 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
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: Range remove [...] But there's another issue here. remove() has other overloads: [...] Two constraints are common to all three, those are the only ones that actually need to be in the constraint. The others can go in the 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!
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Tuesday, 14 February 2017 at 16:25:17 UTC, Andrei Alexandrescu
wrote:
On 02/14/2017 10:49 AM, Jacob Carlborg wrote:
On 2017-02-14 15:37, Andrei Alexandrescu wrote:
How are they so,
Example [1]. That signature spans 8 lines, it took me 10
seconds to find
the actual function name.
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
Re: extern(C) and mangling type names
On Wednesday, 15 February 2017 at 12:32:42 UTC, Kagamin wrote:
On Wednesday, 15 February 2017 at 12:00:51 UTC, Mike Parker
wrote:
version(UseX11) {
struct Display;
alias EGLNativeWindowType = Display*;
}
else version(UseWayland) {
struct wl_display;
EGLNativeWindowType = wgl_display*;
}
If you use void* for Display*, why do you need casts? What do
you cast it to?
In this case I don't of course. Shouldn't have mentioned it in
that context.
Re: extern(C) and mangling type names
On Wednesday, 15 February 2017 at 12:00:51 UTC, Mike Parker wrote:
version(UseX11) {
struct Display;
alias EGLNativeWindowType = Display*;
}
else version(UseWayland) {
struct wl_display;
EGLNativeWindowType = wgl_display*;
}
If you use void* for Display*, why do you need casts? What do you
cast it to?
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 01:09:59 UTC, Chris Wright wrote: Because now I have to look up the definition of fooConstraint and then I have to look up the definition of each element within it. To be honest, I don't often look at function definitions for the template constraints, but 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.
Re: Updating Windows SDK static libraries of the DMD distribution
On Tuesday, 14 February 2017 at 14:11:31 UTC, Sönke Ludwig wrote: It's a quite frequent issue to get unresolved externals on Windows, because the lib files of the Windows platform SDK are still stuck at Windows XP age. It would make a lot of sense to update those to the latest Windows 10 SDK, but I couldn't find a place where those are present physically, except for the release archives. Does anyone know where those are stored or has the means to update them? Martin? You should ping Martin directly via email - I am not sure whether he regularly checks the general NG.
Re: extern(C) and mangling type names
On Wednesday, 15 February 2017 at 10:59:25 UTC, Kagamin wrote:
On Wednesday, 15 February 2017 at 03:40:32 UTC, Mike Parker
wrote:
My specific use case is a binding to a C library that makes
use of specific types from X11, Wayland and elsewhere.
If X11.Foo is implicitly convertible to forward reference Foo
and forward reference Foo is implicitly convertible to
Wayland.Foo, then X11.Foo is implicitly convertible to
Wayland.Foo.
Not quite what I meant. I want to use X11 types without forcing
the user to choose between Tom's X11 bindings and Jerry's. The
user should be able to use either. Ditto for multiple Wayland
bindings. So, for example:
version(UseX11) {
struct Display;
alias EGLNativeWindowType = Display*;
}
else version(UseWayland) {
struct wl_display;
EGLNativeWindowType = wgl_display*;
}
Then when compiling with UseX11, the user can import tom.x11 or
jerry.x11, whichever he prefers.
It's so tantalizingly close to being possible. My earlier example
compiles and runs when using type inference:
module ec3;
void main() {
import ec1, ec2;
auto f = newFoo(30);
printFoo(f);
}
My intuition is screaming at me. If this works, then shouldn't it
also work when I declare the type myself?
And if I add `alias MyFoo = Foo*` to ec1, then the first error,
the one about conflicts, goes away, but I still get the latter
two errors related to the function call. Why? I'm still returning
an ec2.Foo* and assigning it to an ec1.Foo*. An alias is just a
synonym. The types haven't changed.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 09:22:14 UTC, Daniel N wrote:
template every(T...)
{
template satisfies(U...)
{
enum satisfies = true;
}
}
(lunch-break => time to hack D!)
template every(T...)
{
template satisfies(U...)
{
enum satisfies = {
foreach(t; T)
foreach(u; U)
if(!u!t)
return false;
return true;
}();
}
}
Re: Updating Windows SDK static libraries of the DMD distribution
Am 15.02.2017 um 07:43 schrieb Mike Parker: On Tuesday, 14 February 2017 at 20:14:32 UTC, Jonathan M Davis wrote: I would point out that we technically don't support Windows XP. If you use D with it, and it works for you, great, but you're on your own. Which is why the OMF libs need to be updated. They're ancient! That being said, I don't know enough about the Windows SDK to have any clue what we should do with it. If it actually requires Windows 10 to use the Win10 SDK, then I don't see how we could include it by default, since we do support Windows 7 (and most folks I know who use Windows refuse to upgrade beyond 7 until they have to, though there are obviously plenty of folks out there on 8 or 10). It should be fine to just update the libraries to the Win 7 SDK versions. Anyone who actually needs any newer API functions can either use the MS linker or do what we already have to do with the OMF libs and either manually load them via the LoadLibrary API or generate their own. Though, I do recall a discussion on this quite a while ago. I can't remember how it ended. Although the Windows 10 import libraries should work fine for a Windows 7 application, too. At least the 8.1 SDK guarantees backwards compatibility down to Windows 7. The 10 SDK has some breaking changes in the runtime, but that AFAIK doesn't affect the WinAPI import libraries.
Re: D future ...
On Tuesday, 14 February 2017 at 10:22:26 UTC, Ola Fosheim Grøstad wrote: But, the way I see it TypeScript + "native libraries" has the potential for covering a lot of ground. The eco system is exploding. Having done a fair amount of professional development in typescript over the last 6 months, I have to say I'm not as excited about it as I used to be. Don't get me wrong, I still think it's the best language in its space, but the javascript underneath it shows through in a lot of bad places and the lack of real meta-programming makes it hard to get your types exactly how you want them. Overall I've found it a frustrating when I compare it to working in D, despite it having a bunch of cool features I'd love to use in D.
Re: extern(C) and mangling type names
On Wednesday, 15 February 2017 at 03:40:32 UTC, Mike Parker wrote: My specific use case is a binding to a C library that makes use of specific types from X11, Wayland and elsewhere. If X11.Foo is implicitly convertible to forward reference Foo and forward reference Foo is implicitly convertible to Wayland.Foo, then X11.Foo is implicitly convertible to Wayland.Foo.
Re: D future ...
On Tue, 2017-02-14 at 10:22 +, Ola Fosheim Grøstad via Digitalmars- d wrote: > On Saturday, 11 February 2017 at 18:51:31 UTC, Russel Winder > wrote: > > Interesting, but the current competition is between Go, Rust, > > C++, and D. > > I don't know, which fields are you thinking about? I believe the > market is changing. It is also "re-tribalising" around the Rust, Go, Swift, C++17 for native code; Java 8/9, Kotlin, Scala, Groovy, Clojure on the JVM; ECMAScript, TypeScript, Elm in the browser, and Python in data science and such like. OK not orthogonal dimensions. > On OSX/iOS: Swift + Metal is the alternative, throw in some bits > of Objective-C/C++ where you have long running tight inner loops. > > On Windows: moving away from C# sounds very risky. > > On Linux: this is more of an open space. > > Embedded: C/C++, maybe Rust for those with courage? I suspect > moving out of vendor supported tooling is risky (e.g. > system-on-a-chip solutions) > > Numerics: Python + low level libraries, Matlab etc. > > But, the way I see it TypeScript + "native libraries" has the > potential for covering a lot of ground. The eco system is > exploding. An interesting perspective is who is putting money into IDEs and JetBrains are a good measuring device for this. C/C++ with CMake got CLion which is now getting a lot of Swift and Rust love. Go got a whole new IDE in Goglang. C#, Ruby, JavaScript get a lot of push, as do the gamut of JVM languages in IDEA – where the Rust plugin gets a lot of push. Python has PyCharm. D has some small effort in IDEA, but it needs the resourcing to get to the level the Rust, Clojure, Scala, Groovy, Swift, Go, C++, Kotlin languages get. It is noticeably that many people are leaving the Eclipse environment for the JetBrains one, Ceylon is a prime example. But Eclipse remains a player here (unlike NetBeans?) Emacs, VIM, SublimeText, Atom, etc. get some love but few people really care about them compared to the Eclipse and JetBrains IDEs. So if we measure traction by IDE and editor effort D is losing, along with Fantom, Crystal, Pony, Nim, and all the other languages that focus on the language to the expense of the way people use the language. Kingsley started work on the IDEA plugin and Bruno on the Eclipse plugin. Some people are working on the IDEA plugin (I am supposed to be as well, but I am failing). To get D out there with traction, these, not the compiler, should be the core focus of attention – the place where lots of resource is going in. Ceylon, Kotlin, Rust, Go have some core resource that attracts more resource, and there is a snowball effect. No matter how good D and the compilers are, without high quality IDE support, it will be a peripheral language for the core adherents. But we have been round this time and again, with extraordinarily little progress. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Wednesday, 15 February 2017 at 08:59:49 UTC, Jacob Carlborg
wrote:
On 2017-02-15 09:19, Walter Bright wrote:
On 2/14/2017 9:28 PM, Adam D. Ruppe wrote:
On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright
wrote:
A further improvement in the documentation would be to add
links to
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;
}
}
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2017-02-15 09:19, Walter Bright wrote: On 2/14/2017 9:28 PM, Adam D. Ruppe wrote: On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: A further improvement in the documentation would be to add links to isBidirectionalRange and hasLvalueElements. Kneel before your god! 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
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2017-02-14 17:25, Andrei Alexandrescu wrote:
My recollection is past discussions got stalled because the approach is
combinatorially bankrupt. How would one express the constraints of the
functions above with simple named constraints? (Not rhetorical; please
do provide an example if 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
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2017-02-14 17:25, Andrei Alexandrescu wrote:
My recollection is past discussions got stalled because the approach is
combinatorially bankrupt. How would one express the constraints of the
functions above with simple named constraints? (Not rhetorical; please
do provide an example if 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
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2/14/2017 9:28 PM, Adam D. Ruppe wrote: On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: A further improvement in the documentation would be to add links to isBidirectionalRange and hasLvalueElements. Kneel before your god! 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!
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On 2017-02-15 06:28, Adam D. Ruppe wrote: Kneel before your god! http://dpldocs.info/experimental-docs/std.algorithm.mutation.remove.1.html Take a look at this insane automatic cross referencing: http://dpldocs.info/experimental-docs/std.range.chain.html My ref thing still isn't perfect, 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
