"dmd -O" does not support Mir Algorithm
Hi, I added unittest-release builds into Travis. LDC works well but DMD fails in few places. One DMD bug was filled [1]. I will explore others when this is fixed. Please use only LDC for builds with O flag for now. [1] https://issues.dlang.org/show_bug.cgi?id=17943 Best regards, Ilya
Re: Note from a donor
On 10/29/2017 1:03 PM, Benjamin Thaut wrote: Unfortunately I currenlty don't have a lot of spare time to spend on open source projets. I will however have some more time in December. My current plan is to revive DIP 45 and my dll implementation and give it some finishing touches as discussed with Walter at DConf 2017. Looking forward to it!
Re: Note from a donor
On Sunday, 29 October 2017 at 20:58:45 UTC, 12345swordy wrote: What makes you think that windows is a "dying platform"!? There is no evidence to suggest this. Windows dying? Perhaps not. But the dominance of Windows is *certainly* under threat. The clear evidence for that, is the strategies MS is putting in place to go cross-platform, and, increasingly, open-source. Good on em' for adapating... D is focused on its cross-platform capabilites, which wil be really important for its future too... So the evidence is in. Windows is becoming less dominant...and there's no reason to believe that won't continue to be the case... btw. No mobile device will replace my desktop pc ... Like the pharaohs..I want access to my desktop pc in the after life too..so it will be buried with me ;-)
Re: Note from a donor
On Sunday, 29 October 2017 at 16:25:35 UTC, Jonathan M Davis wrote: While complaining about what Microsoft is doing with VS may be justified, it doesn't really help anything. I think that we'd all be better off if we just let this topic die. Not to push the point too much...but I found this interesting phrase, from Google's 'ten things we know to be true' "Ultimately, our constant dissatisfaction with the way things are becomes the driving force behind everything we do." https://www.google.com/about/philosophy.html
Re: Note from a donor
On Sunday, 29 October 2017 at 16:14:11 UTC, 12345swordy wrote: Hell, I even recall that gdb needs python for some strange reason, in my linux machines. I don't know WHY it requires it, but I wouldn't jump to conclusions and think it as "unnecessary-dependencies" simply because I don't understand the rational behind it. Here is an interesting paper, that explores the dependencies between modules in some open source kernels (linux vs BSD). The paper found the linux kernel (compared to the BSD kernels) had far too much dependency between modules, because linux uses far too many global variables, and so too many modules are tightly coupled by mean of them sharing those global variables. They argued that such common coupling (module dependencies) have a deleterious effect on maintainability, and that such common coupling increases exponentially with each subsequent release, further reducing maintainability. The key take away point of course, is that software development really needs to be on guard against the problems associated with modular dependencies. It's one of the reasons functional programming is becoming increasingly important (and useful). There is no reason why the principle should not also apply to the distribution of software. https://dl.acm.org/citation.cfm?id=1150566.1150571
Re: [OT] Windows dying
On Sunday, 29 October 2017 at 23:01:37 UTC, Joakim wrote: It has not been fully replaced _yet_, but that is precisely what is about to happen. You got to try harder then the "because I say so" routine.
Re: Note from a donor
On Sunday, 29 October 2017 at 16:14:11 UTC, 12345swordy wrote: How exactly do you know this? You never justify it! We are living in an age where we have terabytes harddrives! Hell, I even recall that gdb needs python for some strange reason, in my linux machines. I don't know WHY it requires it, but I wouldn't jump to conclusions and think it as "unnecessary-dependencies" simply because I don't understand the rational behind it. I believe that complexity and unnecessary dependencies on components and other teams, is the biggest problem/challenge facing modern software development. It lead to software that is intolerant to change. And it's the primary reason why the Cylons, when they arrive, will defeat us ;-) The D language is so refreshing...that I'd hate to see it get caught up in that mess of complexity. We should all really be on guard against it.
Re: A friendly note on decorum in this group
On Sunday, 29 October 2017 at 19:33:42 UTC, Andrei Alexandrescu wrote: Hi folks, please don't forget that our community prides itself for civil debate mostly without resorting to shutting down threads. Let's keep it that way. Remember - if you'd feel awkward telling something to a colleague in polite company over a beer at a DConf evening, you probably shouldn't tell them here. Thanks! -- Andrei Come on Andrei, what could be less interesting than a civil debate... I mean really ;-) Just look where that got the Catalonians. Having said that, prejudice and derogatory statements should not be accepted. And trolls should not be allowed to control the debate.
Re: [OT] Windows dying
On Sunday, 29 October 2017 at 23:01:37 UTC, Joakim wrote: I'd argue you need to improve on understanding things. Specifically, just as WordStar once dominated the market and is now dead, the same is happening to Word and Windows now. It has not been fully replaced _yet_, but that is precisely what is about to happen. Oh don't worry about that, MS already has a ARM device prototype with native desktop Windows 10 version(with x86 -> ARM translator).
Re: Note from a donor
On Sunday, 29 October 2017 at 16:25:35 UTC, Jonathan M Davis wrote: While complaining about what Microsoft is doing with VS may be justified, it doesn't really help anything. I think that we'd all be better off if we just let this topic die. - Jonathan M Davis That attitude would have you instantly evicted from my team ;-) It's precisely because of the 'complaining' that Microsoft is changing its ways'. Complain even 'louder'...that's my advice. -- The only real problem with Windows, is that you can't fork it --
Re: Project Elvis
On Monday, 30 October 2017 at 00:10:13 UTC, w0rp wrote: One man's valid value is another man's invalid value. You can't test for a general concept of "invalid," as you need context. You can test for "falsy" with no context. No, associating the numeral "0" with "false" is forcing a particular interpretation of int as representing a count of something. That is not an inate quality of the integer programming language type as such. For instance, there is no reason for "0 fahrenheit" to be "false". Only if "0" represents the "empty set" would that interpretation make some sense. Yes, you can obviously have a general concept of invalid in a strict typing system.
Re: Project Elvis
One man's valid value is another man's invalid value. You can't test for a general concept of "invalid," as you need context. You can test for "falsy" with no context.
Re: [OT] Windows dying
On Sunday, 29 October 2017 at 22:48:56 UTC, 12345swordy wrote: On Sunday, 29 October 2017 at 22:36:04 UTC, Joakim wrote: On Sunday, 29 October 2017 at 22:29:01 UTC, 12345swordy wrote: On Sunday, 29 October 2017 at 22:22:23 UTC, Joakim wrote: I suggest you read up on some computing history, start with WordStar: https://en.m.wikipedia.org/wiki/WordStar I fail to see how Wordstar is relevant. Perhaps that's why you're missing every other thing I'm pointing out too. The fact that is currently abandon and there isn't anything mobile related in the article that I just scan read? Yea, you need to improve on explaining things. I'd argue you need to improve on understanding things. Specifically, just as WordStar once dominated the market and is now dead, the same is happening to Word and Windows now. Regardless people are 0not going to use mobile in the work place. If that's so, I suspect the "work place" will become irrelevant. LOL Ok, now I know you talking nonsense. You crusade against windows OS support is pointless. I don't crusade against anything. I simply point out that wasting time on a dying platform is not the best use of D tool devs' time. Newsflash, it's not "dying". The mobile market is NOT going to single handily replace the laptop and desktop market. It has not been fully replaced _yet_, but that is precisely what is about to happen.
Re: [OT] Windows dying
On Sunday, 29 October 2017 at 22:36:04 UTC, Joakim wrote: On Sunday, 29 October 2017 at 22:29:01 UTC, 12345swordy wrote: On Sunday, 29 October 2017 at 22:22:23 UTC, Joakim wrote: I suggest you read up on some computing history, start with WordStar: https://en.m.wikipedia.org/wiki/WordStar I fail to see how Wordstar is relevant. Perhaps that's why you're missing every other thing I'm pointing out too. The fact that is currently abandon and there isn't anything mobile related in the article that I just scan read? Yea, you need to improve on explaining things. Regardless people are 0not going to use mobile in the work place. If that's so, I suspect the "work place" will become irrelevant. LOL Ok, now I know you talking nonsense. You crusade against windows OS support is pointless. I don't crusade against anything. I simply point out that wasting time on a dying platform is not the best use of D tool devs' time. Newsflash, it's not "dying". The mobile market is NOT going to single handily replace the laptop and desktop market.
Re: [OT] Windows dying
On Sunday, 29 October 2017 at 22:29:01 UTC, 12345swordy wrote: On Sunday, 29 October 2017 at 22:22:23 UTC, Joakim wrote: I suggest you read up on some computing history, start with WordStar: https://en.m.wikipedia.org/wiki/WordStar I fail to see how Wordstar is relevant. Perhaps that's why you're missing every other thing I'm pointing out too. Regardless people are 0not going to use mobile in the work place. If that's so, I suspect the "work place" will become irrelevant. You crusade against windows OS support is pointless. I don't crusade against anything. I simply point out that wasting time on a dying platform is not the best use of D tool devs' time. They're then free to do whatever they want with that info.
Re: [OT] Windows dying
On Sunday, 29 October 2017 at 22:22:23 UTC, Joakim wrote: I suggest you read up on some computing history, start with WordStar: https://en.m.wikipedia.org/wiki/WordStar I fail to see how Wordstar is relevant. Regardless people are not going to use mobile in the work place. You crusade against windows OS support is pointless.
Re: [OT] Windows dying
On Sunday, 29 October 2017 at 21:59:36 UTC, 12345swordy wrote: On Sunday, 29 October 2017 at 21:36:50 UTC, Joakim wrote: pointed out there, mobiles are coming after the desktop and laptop markets, and will likely kill off Wintel in the coming years. No, they are not "coming after the desktop and markets", that's a ridiculous claim to make. You know why, because I hear the same claim being made back 5-7 years ago. People are not going to use mobile for typing up their MS word documents. Claims that were made 5-7 years ago can often come true later, :) and I already showed you that Samsung is pursuing it. Nobody will type up MS Word docs on their mobile alone, but they can do it with a Galaxy S8 in a Dex dock now, and soon won't be using Word or Office altogether. If you don't believe me, I suggest you read up on some computing history, start with WordStar: https://en.m.wikipedia.org/wiki/WordStar
Re: [OT] Windows dying
On Sunday, 29 October 2017 at 21:36:50 UTC, Joakim wrote: pointed out there, mobiles are coming after the desktop and laptop markets, and will likely kill off Wintel in the coming years. No, they are not "coming after the desktop and markets", that's a ridiculous claim to make. You know why, because I hear the same claim being made back 5-7 years ago. People are not going to use mobile for typing up their MS word documents.
Re: [OT] Windows dying
On Sunday, 29 October 2017 at 21:30:06 UTC, 12345swordy wrote: On Sunday, 29 October 2017 at 21:21:58 UTC, Joakim wrote: On Sunday, 29 October 2017 at 20:58:45 UTC, 12345swordy wrote: On Sunday, 29 October 2017 at 18:52:06 UTC, Joakim wrote: [...] What makes you think that windows is a "dying platform"!? There is no evidence to suggest this. Take a look at the links in the thread I linked you, which show PC sales dropping for the last six years and back at the level of a decade ago. Mobile market != Desktop market. Windows still have the majority of the Desktop market. https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0 Sure, but most people compute and run apps on mobiles. As I pointed out there, mobiles are coming after the desktop and laptop markets, and will likely kill off Wintel in the coming years.
Re: [OT] Windows dying
On Sunday, 29 October 2017 at 21:21:58 UTC, Joakim wrote: On Sunday, 29 October 2017 at 20:58:45 UTC, 12345swordy wrote: On Sunday, 29 October 2017 at 18:52:06 UTC, Joakim wrote: [...] What makes you think that windows is a "dying platform"!? There is no evidence to suggest this. Take a look at the links in the thread I linked you, which show PC sales dropping for the last six years and back at the level of a decade ago. Mobile market != Desktop market. Windows still have the majority of the Desktop market. https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0
[OT] Windows dying
On Sunday, 29 October 2017 at 20:58:45 UTC, 12345swordy wrote: On Sunday, 29 October 2017 at 18:52:06 UTC, Joakim wrote: [...] What makes you think that windows is a "dying platform"!? There is no evidence to suggest this. Take a look at the links in the thread I linked you, which show PC sales dropping for the last six years and back at the level of a decade ago.
Re: Note from a donor
On Sunday, 29 October 2017 at 18:52:06 UTC, Joakim wrote: On Sunday, 29 October 2017 at 10:21:22 UTC, Patrick Schluter wrote: To conclude: if D wants to cater to that crowd, it will have to bite the bullet and make the Windows experience even smoother than it is now. You won't overcome Windows dev's Stockholm syndrome otherwise and Windows devs, should also peg down a little bit and learn that MS's way of doing things is far from being ideal (bloat, loss of control, changing specs every 3 years, programmed obsolescence (Active-X anyone?)). Or better yet, don't bother with a dying platform full of whiny devs who are helpless without an IDE. One of D's strengths is that it isn't architected for IDE-driven development and the oft-resulting verbosity, that's a market D should probably just leave alone. Instead, focus on the current major platform which lets you use almost any toolchain you want: http://forum.dlang.org/thread/xgiwhblmkvcgnsktj...@forum.dlang.org Of course, it is admirable what Rainer and others do to maintain VisualD and other D tools for the Windows platform. I just don't see it mattering much in the next decade. What makes you think that windows is a "dying platform"!? There is no evidence to suggest this.
Re: Project Elvis
On Sunday, 29 October 2017 at 20:37:21 UTC, bauss wrote: But casting to bool is what you use to tell whether something is valid or not. true = valid, false = invalid. Not really. In mathematics 0 and 1 can be considered as "true" and "false" for a 2-value calculus, while you might reserve ⊤ and ⊥ for true and false in the logic you use to reason about that calculus. Which is why some languages assumes an equality between 0 and true and 1 and false, but that does not by necessity suggest valid/invalid. On the other hand. For things like Unix function call return values -1 is often used to signify an invalid result, and 0 does not signify failure. So if you want strict typing, you have to do something else. Because C (and thus D) takes the mathematical view on the relationship between integers and bools and propagate that view to all other basic types (e.g. floats). Ola.
Re: Project Elvis
On Sunday, 29 October 2017 at 20:15:41 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 29 October 2017 at 20:05:08 UTC, Steven
Schveighoffer wrote:
It's actually perfect for generic code. If you need something
other than the current "0 means false" behavior (like for
instance int), then you wrap in a type that opCast!bool means
what you want.
I think we just have to agree that we disagree. Generic
programming relies on consistent protocols.
So, you generally don't want 0 to be considered as an invalid
value. Because of the defaults in D, cast(bool) isn't really
all that useful.
It would have been better if the default was to deny casting to
bool, but that is too late as D has decided to be too close to
C on so many levels, so it would be a bad idea to diverge from
C for that now. So the next best thing is to let the programmer
specify that something is invalid with some other means than
opCast to bool.
*shrug*
But casting to bool is what you use to tell whether something is
valid or not.
true = valid, false = invalid.
If you want 0 to be valid for a type then you wrap around it with
opCast.
Ex.
---
import std.stdio;
struct MyInt
{
int value;
bool opCast(T : bool)()
{
return value >= 0;
}
}
void main()
{
MyInt a = MyInt(1);
MyInt b = MyInt(0);
MyInt c = MyInt(-1);
if (a) writeln("a is valid");
if (b) writeln("b is valid");
if (c) writeln("c is valid");
}
---
Output:
a is valid
b is valid
Re: Project Elvis
On Sunday, 29 October 2017 at 20:05:08 UTC, Steven Schveighoffer wrote: It's actually perfect for generic code. If you need something other than the current "0 means false" behavior (like for instance int), then you wrap in a type that opCast!bool means what you want. I think we just have to agree that we disagree. Generic programming relies on consistent protocols. So, you generally don't want 0 to be considered as an invalid value. Because of the defaults in D, cast(bool) isn't really all that useful. It would have been better if the default was to deny casting to bool, but that is too late as D has decided to be too close to C on so many levels, so it would be a bad idea to diverge from C for that now. So the next best thing is to let the programmer specify that something is invalid with some other means than opCast to bool. *shrug*
Re: Project Elvis
On Sunday, 29 October 2017 at 18:02:25 UTC, Jonathan M Davis wrote: Sounds like a bug to me. NaN is supposed to be false whenever it's used in a comparison. If it it's true when cast directly to bool, then that's inconsistent. It is consistent with C...
Re: Project Elvis
On 10/29/17 12:29 PM, Ola Fosheim Grøstad wrote: On Sunday, 29 October 2017 at 15:57:19 UTC, Steven Schveighoffer wrote: I would have expected Nullable!int to fit the bill, but unfortunately, opCast(bool) doesn't work on a null Nullable. But certainly you can construct a type that does work. The right thing to do is to create a type that you cannot cast to bool, but where you can test for invalid values and substitute in a default. This is pretty simple, the if(x) provides a mechanism to check called "casting to bool". That doesn't mean it will shoehorn bool into the expression. In fact, the elvis operator provides a perfect way to type the result with the "common type" rules of D. The way to do it is to make a type that checks whether the expression is valid or not, makes that into a bool, and then provides the real expression to the result. Forcing people to have a boolean interpretation of a type mean valid/invalid state has viral consequences. It means that if the type has a zero value then a boolean interpretation of zero now should give true. That's not good for generic code. It's actually perfect for generic code. If you need something other than the current "0 means false" behavior (like for instance int), then you wrap in a type that opCast!bool means what you want. It should work just like a pointer. In swift this is exactly what the ? operator does. I just wish Nullable worked this way, I'm surprised it doesn't. -Steve
Re: Note from a donor
On Tuesday, 24 October 2017 at 21:11:38 UTC, solidstate1991 wrote: DIP45 has the solution (make export an attribute), it needs to be updated for the new DIP format from what I heard. It needs to be pushed, as Windows still the most popular OS on the consumer side of things, then we can have Phobos and DRuntime as DLLs without using experimental versions of DMD. I have some plans with the better DLL support, such as the possibility of a D based Python (for better class interoperability with D), or even using a modified set of D for scripting (eg. SafeD only). Unfortunately I currenlty don't have a lot of spare time to spend on open source projets. I will however have some more time in December. My current plan is to revive DIP 45 and my dll implementation and give it some finishing touches as discussed with Walter at DConf 2017.
A friendly note on decorum in this group
Hi folks, please don't forget that our community prides itself for civil debate mostly without resorting to shutting down threads. Let's keep it that way. Remember - if you'd feel awkward telling something to a colleague in polite company over a beer at a DConf evening, you probably shouldn't tell them here. Thanks! -- Andrei
Re: Project Elvis
On Sunday, 29 October 2017 at 18:02:25 UTC, Jonathan M Davis
wrote:
On Sunday, October 29, 2017 17:35:25 Nemanja Boric via
Digitalmars-d wrote:
On Sunday, 29 October 2017 at 17:19:44 UTC, Jonathan M Davis
wrote:
> On Sunday, October 29, 2017 16:44:39 Ola Fosheim Grøstad via
>
> Digitalmars-d wrote:
>> On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis
>>
>> wrote:
>> > valid using ?:, I would think that you'd want to be doing
>> > the same check with stuff like if statements anyway. So,
>> > it sounds to me like overloading opCast!bool would work
>> > just fine.
>>
>> If you try to do:
>>
>> some_float ?: 0.0
>>
>> then it will do nothing as cast(bool)std.math.NaN(0) => true
>
> NaN is supposed to always be false.
OT, but I had to :-)
```
void main()
{
import std.stdio;
float x;
x? writeln("Oh no, a NaN!") : writeln("All good.");
}
```
Same happens for assert(float.nan) - it doesn't fail.
Sounds like a bug to me. NaN is supposed to be false whenever
it's used in a comparison. If it it's true when cast directly
to bool, then that's inconsistent.
- Jonathan M Davis
We've already reported this as a bug (I actually got quite burned
on it, trusting assert(float_value) to prevent NaN's escaping the
function), but there were different opinions on this, so it never
got anywhere: https://issues.dlang.org/show_bug.cgi?id=13489
Re: Note from a donor
On Sunday, 29 October 2017 at 10:21:22 UTC, Patrick Schluter wrote: To conclude: if D wants to cater to that crowd, it will have to bite the bullet and make the Windows experience even smoother than it is now. You won't overcome Windows dev's Stockholm syndrome otherwise and Windows devs, should also peg down a little bit and learn that MS's way of doing things is far from being ideal (bloat, loss of control, changing specs every 3 years, programmed obsolescence (Active-X anyone?)). Or better yet, don't bother with a dying platform full of whiny devs who are helpless without an IDE. One of D's strengths is that it isn't architected for IDE-driven development and the oft-resulting verbosity, that's a market D should probably just leave alone. Instead, focus on the current major platform which lets you use almost any toolchain you want: http://forum.dlang.org/thread/xgiwhblmkvcgnsktj...@forum.dlang.org Of course, it is admirable what Rainer and others do to maintain VisualD and other D tools for the Windows platform. I just don't see it mattering much in the next decade.
Re: Project Elvis
On Sunday, October 29, 2017 17:35:25 Nemanja Boric via Digitalmars-d wrote:
> On Sunday, 29 October 2017 at 17:19:44 UTC, Jonathan M Davis
>
> wrote:
> > On Sunday, October 29, 2017 16:44:39 Ola Fosheim Grøstad via
> >
> > Digitalmars-d wrote:
> >> On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis
> >>
> >> wrote:
> >> > valid using ?:, I would think that you'd want to be doing
> >> > the same check with stuff like if statements anyway. So, it
> >> > sounds to me like overloading opCast!bool would work just
> >> > fine.
> >>
> >> If you try to do:
> >>
> >> some_float ?: 0.0
> >>
> >> then it will do nothing as cast(bool)std.math.NaN(0) => true
> >
> > NaN is supposed to always be false.
>
> OT, but I had to :-)
>
> ```
> void main()
> {
> import std.stdio;
>
> float x;
> x? writeln("Oh no, a NaN!") : writeln("All good.");
> }
> ```
>
> Same happens for assert(float.nan) - it doesn't fail.
Sounds like a bug to me. NaN is supposed to be false whenever it's used in a
comparison. If it it's true when cast directly to bool, then that's
inconsistent.
- Jonathan M Davis
Re: Project Elvis
On Sunday, 29 October 2017 at 17:19:44 UTC, Jonathan M Davis
wrote:
On Sunday, October 29, 2017 16:44:39 Ola Fosheim Grøstad via
Digitalmars-d wrote:
On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis
wrote:
> valid using ?:, I would think that you'd want to be doing
> the same check with stuff like if statements anyway. So, it
> sounds to me like overloading opCast!bool would work just
> fine.
If you try to do:
some_float ?: 0.0
then it will do nothing as cast(bool)std.math.NaN(0) => true
NaN is supposed to always be false.
OT, but I had to :-)
```
void main()
{
import std.stdio;
float x;
x? writeln("Oh no, a NaN!") : writeln("All good.");
}
```
Same happens for assert(float.nan) - it doesn't fail.
Re: Proposal: Object/?? Destruction
On Monday, 16 October 2017 at 23:29:46 UTC, sarn wrote:
On Sunday, 15 October 2017 at 15:19:21 UTC, Q. Schroll wrote:
On Saturday, 14 October 2017 at 23:20:26 UTC, sarn wrote:
On Saturday, 14 October 2017 at 22:20:46 UTC, Q. Schroll
wrote:
Therefore, and because of brackets, you can distinguish f(1,
2) from f([1, 2]).
But in f([1, 2]), it's ambiguous (just by parsing) whether
[1, 2] is a tuple literal or a dynamic array literal.
It would be a tuple if that's the best match, otherwise
conversion to int[] is tried.
...
You'd need to use a prefix or something to the bracket syntax.
[snip]
I just argued, you don't!
But have you thought through all the implications?
Yes. No weirdness is being introduced that is not there already.
Maybe I have overseen something; I will not give you or anyone
else a guarantee for the solution to work perfectly. I've thought
through the case very long.
An open question is allowing partly const/immutable/shared (cis)
tuples. As for now, I didn't care. Even c/i/s-homogeneus tuples
(the tuple is c/i/s as a whole or not) would be a win in my
opinion. One rarely needs tuples with one component immutable but
the other one mutable. This is what a named struct is for. On the
other hand, I don't know of any issues having a to partly c/i/s
std.typecons.Tuple.
Take this code:
void main(string[] args)
{
import std.stdio : writeln;
writeln([1, 3.14]);
}
As you're probably 100% aware, this is totally valid D code
today. [1, 3.14] becomes a double[] because 1 gets converted
to a double.
Right conclusion with insufficient explanation. [1, 3.14] is a
static array in the first place. It occupies a fully inferred
template parameter position. I don't know the implementation, but
every time I tested, it behaves as if typeof(expr) is being used
after the bang to set the template argument manually (even for
Voldemort types etc. where typeof is sometimes impossible due to
missing frame pointers). typeof returns "dynamic array of T" for
array literals. This is all the weirdness going on here. It is
present today and would remain present if you interpret [1, 3.14]
as a tuple.
If this kind of behaviour changes, code will break, so you'll
need a bunch of exceptions to the "it would be a tuple if
that's the best match" rule.
The only exception is typeof and (therefore, I don't know...)
template inference.
Also, for the same backwards compatibility reasons, it would be
impractical in most cases to add any tuple overloads to most
existing standard library functions that currently accept
slices or arrays, but presumably new functions would be meant
to take advantage of the new syntax (else there wouldn't be
much point creating a new syntax).
You don't have to as long as you don't want to support tuples
explicitly; otherwise you have to. If you have a void f(int,
double), you cannot plug in [1, 3.14]. You can use some expand to
do it. You wouldn't want to either. If you have something
*explicitly typed* as a tuple, e.g.
[int, double] tup = [1, 3.14];
you can make the call f(tup) because auto expansion does its job.
This is the use case. If you have void f([int, double]), you can
plug in tuple literals.
If you use a tuple literal for a function call, the compiler will
search for explicit matches for tuples. If it cannot find any,
conversion to a dynamic array happens.
So, a literal like [1, 3.14] would basically be a tuple, but
would be converted to double[] in a bunch of special cases for
historical reasons.
Yes. It would be converted in almost all cases -- the same with
static arrays -- because the best match doesn't occur very often
and typeof never returns static arrays or tuples for literals.
If you're not sure if this is really a problem, take a look at
the confusion caused by the magic in {} syntax:
https://forum.dlang.org/thread/ecwfiderxbfqzjcyy...@forum.dlang.org
https://forum.dlang.org/thread/ihsmxiplprxwlqkgw...@forum.dlang.org
https://forum.dlang.org/thread/qsayoktyffczskrnm...@forum.dlang.org
This is completely unrelated. Concerning the issues people have
with (..) => { .. }, I've filed an enhancement request to
deprecate it in that specific case:
https://issues.dlang.org/show_bug.cgi?id=17951
To be totally honest, I still don't see what's wrong with just
creating a new bracket syntax, instead of adding more magic to
[] (or () for that matter).
It's not adding any magic to [] that isn't there already. The
other proposals are adding magic to (). Even some mathematicians
use chevrons (angle brackets) for tuples as they see parentheses
as indicators of precedence. I'd vote against angle brackets, see
C++ templates for reasons. Logicians and haskellers even don't
need parentheses for function calls.
Could I convince you?
Re: Project Elvis
On Sunday, October 29, 2017 16:44:39 Ola Fosheim Grøstad via Digitalmars-d
wrote:
> On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis
>
> wrote:
> > valid using ?:, I would think that you'd want to be doing the
> > same check with stuff like if statements anyway. So, it sounds
> > to me like overloading opCast!bool would work just fine.
>
> If you try to do:
>
> some_float ?: 0.0
>
> then it will do nothing as cast(bool)std.math.NaN(0) => true
NaN is supposed to always be false.
> But that is just one of many possible examples. The elvis
> operator as proposed does not match on nullity / invalid state.
Well, the closest that the language has to that is cast(bool). There is
nothing else generic for anything along those lines. If you want something
else, then just use the ternary operator with whatever condition you want to
be testing. It works just fine and isn't much longer.
Personally, I don't think that the Elvis operator is worth much - at least
not in D. Idiomatic D code doesn't use classes much. Dynamic arrays largely
conflate null with empty. Very little does anything with null - especially
if you're writing range-based code - and I've rarely seen code where
x ? x : y was used. The closest that I've typically seen or done to
x ? x : y is
if(auto var = foo())
{
}
and that's not useful for much beyond dealing with functions that return
error codes or getting values from associative arrays. And it's not like
using the ternary operator is very verbose. But the whole idea of "check if
this is valid, if it is use it, and if it isn't, use a default" simply isn't
an idiom that I use much, and I don't think that it's very common in Phobos.
I also tend to prefer being explicit about conditions, so I don't typically
rely on things like cast(bool) on types, and that's exactly the sort of
thing that the Elvis operator would rely on whether it used cast(bool) or it
was overloaded as its own operator like you seem to want.
So, I really don't think that there's any point in adding the Elvis
operator, but there are some folks here who seem to think that it's a great
loss that we don't have it, because they're used to writing stuff like that
in languages like C#, which do way more with classes and null than D code
typically does.
- Jonathan M Davis
Re: Project Elvis
On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis wrote: valid using ?:, I would think that you'd want to be doing the same check with stuff like if statements anyway. So, it sounds to me like overloading opCast!bool would work just fine. If you try to do: some_float ?: 0.0 then it will do nothing as cast(bool)std.math.NaN(0) => true But that is just one of many possible examples. The elvis operator as proposed does not match on nullity / invalid state.
Re: Project Elvis
On Sunday, October 29, 2017 16:18:43 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Sunday, 29 October 2017 at 14:37:57 UTC, Jonathan M Davis > > wrote: > > everything, but I could have missed something). As proposed > > thus far, the Elvis operator is just the ternary operator where > > the condition is reused as the first branch, so having it work > > with opCast fits in perfectly with everything else. > > I understand that it is being defined as a short hand for the > ordinary ternary operator, but if you look at the use context the > elvis-operator tend to be used to filter out invalid state. > > So if casting to bool would test for validity then it would make > more sense, but that is not the general case... > > > What would you be looking to do that does not fit in with this? > > I think it would be better to have a test for validity and use > that for substituting in default values (which is what the elvis > operator is typically used for). And what does testing for validity even mean? Doesn't that depend on the type? I would argue that with regards to the built-in types what cast(bool) does for them is as close to checking for validity as you're going to get, and for user-defined types, they can then just overload opCast!bool to mean whatever they want so long as the result is true or false. In general, if you're looking to check whether something is valid using ?:, I would think that you'd want to be doing the same check with stuff like if statements anyway. So, it sounds to me like overloading opCast!bool would work just fine. - Jonathan M Davis
Re: Project Elvis
On Sunday, 29 October 2017 at 15:57:19 UTC, Steven Schveighoffer wrote: I would have expected Nullable!int to fit the bill, but unfortunately, opCast(bool) doesn't work on a null Nullable. But certainly you can construct a type that does work. The right thing to do is to create a type that you cannot cast to bool, but where you can test for invalid values and substitute in a default. Forcing people to have a boolean interpretation of a type mean valid/invalid state has viral consequences. It means that if the type has a zero value then a boolean interpretation of zero now should give true. That's not good for generic code. Float and NaN is another use case.
Re: Note from a donor
On Sunday, October 29, 2017 16:14:11 12345swordy via Digitalmars-d wrote: > On Sunday, 29 October 2017 at 02:39:21 UTC, codephantom wrote: > > On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote: > > > > What I am, is: > > > > anti-bloat > > anti-too-many-unecessary-dependencies > > anti > > you-have-no-choice-but-to-download-GB's-stuff-you-really-don't-need > > How exactly do you know this? You never justify it! We are living > in an age where we have terabytes harddrives! Hell, I even recall > that gdb needs python for some strange reason, in my linux > machines. I don't know WHY it requires it, but I wouldn't jump to > conclusions and think it as "unnecessary-dependencies" simply > because I don't understand the rational behind it. Really, it doesn't matter. Yes, it would be great if VS didn't take up as much space as it does. It would be great if Microsoft released stuff with the idea that the core compiler command-line tools were what mattered, and the IDE was just an add-on for those who care. I'm sure that we could all come up with reasons to complain about what Microsoft is doing - _lots_ of geeks love to complain about Microsoft. What matters is that D needs to be able to link and interoperate with C/C++ code generated by Microsoft's compiler, because that's the primary compiler for Windows systems and what most everyone is using if they're developing on Windows. If we can do that in a way that minimizes what needs to be downloaded, then great. If we can't, then well, that sucks, but that's life. While complaining about what Microsoft is doing with VS may be justified, it doesn't really help anything. I think that we'd all be better off if we just let this topic die. - Jonathan M Davis
Re: Project Elvis
On Sunday, 29 October 2017 at 14:37:57 UTC, Jonathan M Davis wrote: everything, but I could have missed something). As proposed thus far, the Elvis operator is just the ternary operator where the condition is reused as the first branch, so having it work with opCast fits in perfectly with everything else. I understand that it is being defined as a short hand for the ordinary ternary operator, but if you look at the use context the elvis-operator tend to be used to filter out invalid state. So if casting to bool would test for validity then it would make more sense, but that is not the general case... What would you be looking to do that does not fit in with this? I think it would be better to have a test for validity and use that for substituting in default values (which is what the elvis operator is typically used for).
Re: Note from a donor
On Sunday, 29 October 2017 at 02:39:21 UTC, codephantom wrote: On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote: What I am, is: anti-bloat anti-too-many-unecessary-dependencies anti you-have-no-choice-but-to-download-GB's-stuff-you-really-don't-need How exactly do you know this? You never justify it! We are living in an age where we have terabytes harddrives! Hell, I even recall that gdb needs python for some strange reason, in my linux machines. I don't know WHY it requires it, but I wouldn't jump to conclusions and think it as "unnecessary-dependencies" simply because I don't understand the rational behind it.
Re: Project Elvis
On 10/29/17 10:35 AM, Ola Fosheim Grøstad wrote: On Sunday, 29 October 2017 at 14:27:34 UTC, Ola Fosheim Grøstad wrote: On Sunday, 29 October 2017 at 11:23:19 UTC, Steven Schveighoffer wrote: So, what will the member function be called? «opElvis»? No… opCast for bool. That means you cannot create your own type-safe filtering mechanism, but will be forced to provide opCast for bool. That breaks down if you want do filter out invalid values where zero is a valid value. For instance if you have an integer type that tracks overflow: calc(maybe_overflow_integer :? 0) So casting to bool is a poor choice for the typical use context. I would have expected Nullable!int to fit the bill, but unfortunately, opCast(bool) doesn't work on a null Nullable. But certainly you can construct a type that does work. -Steve
Re: Project Elvis
On Sunday, 29 October 2017 at 14:27:34 UTC, Ola Fosheim Grøstad wrote: On Sunday, 29 October 2017 at 11:23:19 UTC, Steven Schveighoffer wrote: So, what will the member function be called? «opElvis»? No… opCast for bool. That means you cannot create your own type-safe filtering mechanism, but will be forced to provide opCast for bool. That breaks down if you want do filter out invalid values where zero is a valid value. For instance if you have an integer type that tracks overflow: calc(maybe_overflow_integer :? 0) So casting to bool is a poor choice for the typical use context.
Re: Project Elvis
On Sunday, October 29, 2017 14:27:34 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Sunday, 29 October 2017 at 11:23:19 UTC, Steven Schveighoffer > > wrote: > >> So, what will the member function be called? «opElvis»? No… > > > > opCast for bool. > > That means you cannot create your own type-safe filtering > mechanism, but will be forced to provide opCast for bool. opCast with bool is precisely how you already provide overloads for dealing with every other place in the language that a boolean condition is used - the ternary operator, assertions, if statements, while loops, and for loops (which I think is everything, but I could have missed something). As proposed thus far, the Elvis operator is just the ternary operator where the condition is reused as the first branch, so having it work with opCast fits in perfectly with everything else. What would you be looking to do that does not fit in with this? - Jonathan M Davis
Re: Project Elvis
On Sunday, 29 October 2017 at 11:23:19 UTC, Steven Schveighoffer wrote: So, what will the member function be called? «opElvis»? No… opCast for bool. That means you cannot create your own type-safe filtering mechanism, but will be forced to provide opCast for bool.
Re: Note from a donor
On Sunday, 29 October 2017 at 10:21:22 UTC, Patrick Schluter wrote: Just a little answer so that you see that you're not alone with your concerns. I think you're absolutely right and that your experiment was nicely done and clear from the beginning what it was about. Reading is a skill that some people seem to have problems with. Thanks for the support ;-) btw. I was just experimenting with the Windows 7 SDK iso (a 570MB download) https://www.microsoft.com/en-au/download/details.aspx?id=8442 From that ISO, I only need to install two components: - Header and Libraries (only the x64 ones are needed) (~180MB) - Visual C++ Compilers (~637MB) The total disk space needed to install those 2 components is 810MB. Then I can compile D using -m64 However DMD won't pick up the SDK during install, so I had to change these two settings in the sc.ini: VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ WindowsSdkDir=C:\Program Files\Microsoft SDKs\Windows\v7.1\ To my surprise (not really knowing what I was doing), it all worked (so far), and apart from downloading the iso, you don't need to be connected to the internet during the install of the SDK... The SDK requires you have .NET 4 installed first though, otherwise it won't let you install the Visual C++ Compilers. btw. The min size if you use the VS 2017 build tools was 3.5GB installed. So I have saved myself several gb of download, and several gb of disk space...just by using the Windows 7 SDK instead.
Re: Project Elvis
On Sunday, 29 October 2017 at 10:08:41 UTC, Ola Fosheim Grøstad wrote: On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote: expr1 ?: expr2 So, what will the member function be called? «opElvis»? No… opCast for bool. -Steve
Re: Note from a donor
On Sunday, 29 October 2017 at 03:46:35 UTC, codephantom wrote: On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote: It seems to me that you have a major case of anti-windows bias here, as I never have any issues on my main windows machine. Actually, it's the very opposite...I'm strongly arguing 'for' D on Windows. (otherwise I wouldn't have wasted my time with this). If you're ok with having VS, then that is not too much of pain to install..I get it. But if you don't want VS, then it really is a pain. You have to work out what is the min required componentsall by yourself - like i had to do. That really was a pain! I want D on Windows (64bit included), and I want it to be a better experience than what I had...that's been the whole point of my involvement in the discussion. In essence, I'm an advocate for D on Windows ;-) (but to do that, without being forced to advocate for VS as well..is kinda challenging..it seems) It's D I'm interested in. Not VS. Just a little answer so that you see that you're not alone with your concerns. I think you're absolutely right and that your experiment was nicely done and clear from the beginning what it was about. Reading is a skill that some people seem to have problems with. To my experience now. I finally managed to install VS2017 by doing essentially the sleep during download thing to get the offline installer. My Internet is not especially bad but not good either (5 Mb down, 1 Mb up ADSL with very fluctuating latencies) and the download took also several hours. For 1.6 GB it's really slow. It has probably more to do with the Microsoft download code than anything else (as the discussions in the link someone provided tend to show). The good thing is that it is now possible to install VS2017 on a relatively small system partition, a thing that I didn't manage to do with VS2013 and VS2015. The DMD installer also had no problem to install the Visual-D plug-in and I managed to build my project in 32 and 64 bit. This said, it's the whole VS experience that I'm really annoyed with. MS goes really out of its way to make the whole IDE as magical as possible, i.e. everything is set so that the gritty reality of code generation is hidden from the developer. The more it goes, the less obvious it gets to install unconventional things in the environment. Even simple stuff can become a real pain. For instance, I like to have visible white spaces when editing code (yeah, I hate tabs in program code). In all editors and IDE I have tried yet, it was easy to set, when not in an appearance toolbar, it's somewhere in "view" or "edit" menu. In VS, it was a chore to find and I had to customize a tool bar using 5 deep dialog box galore. Annoying. I can understand how and why MS do it that way. When you work a little bit longer with it, it is really sleek and nicely integrated in the system. The thing is, it that it removes the perspective of what really happens when building a program (object files, libs, linking etc.) and that's the reason why we get so regularely the complaints about the "Windows experience sucking": MS has nurtured a generation of devs who have no clue what building an app entails. To conclude: if D wants to cater to that crowd, it will have to bite the bullet and make the Windows experience even smoother than it is now. You won't overcome Windows dev's Stockholm syndrome otherwise and Windows devs, should also peg down a little bit and learn that MS's way of doing things is far from being ideal (bloat, loss of control, changing specs every 3 years, programmed obsolescence (Active-X anyone?)).
Re: Project Elvis
On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote: expr1 ?: expr2 So, what will the member function be called? «opElvis»? No…
Re: Required Reading: "How Non-Member Functions Improve Encapsulation"
On Sunday, October 29, 2017 08:45:15 w0rp via Digitalmars-d wrote: > I've noticed the benefits of writing non member functions in > Python codebases. Say if you have a User model in a Django ORM, > and you have a Thing model, and some operation on User and Thing. > I've noticed that your code is almost always better if you write > a non member function on User and Thing, instead of a member of > User or Thing. Yeah, making functions generic can be a big win. The bigger question is what to do when it doesn't really make sense to make the function generic, and it doesn't need access to the private members of the type that it would always be used with. In that case, it doesn't need to be a member function, but it could be. - Jonathan M Davis
Re: Required Reading: "Functional Programming in C++"
On Saturday, 28 October 2017 at 23:26:11 UTC, Jonathan M Davis wrote: The type system can help ensure the correctness of functional programming (e.g. pure helps ensure that you didn't accidentally do something involving global variables), but it's certainly not required to write in that style. Yes, the type-system would prevent some aspects of non-functional programming, but it doesn't enable functional programming… Anyway, both C++ and D have abstraction mechanisms for building the tools you need to get functional-style programming. And I assume production backends also do tail-call optimization in D as well as C++. What you don't get in either is a convenient applicative pattern matching syntax, and functional programming in the technical recursive sense is mostly not a very good idea (even with tail call optimization since you cannot enforce it, I think?). Anyway, with the improvements to C++ lambdas it has become more attractive to do small-scale functional style programming in C++. So I think D and C++ are pretty much the same in that respect. (D has pure, but C++ has explicit capturing of references) And actually, most D code that's functional doesn't do much with either const or pure. Most of the functional code is range-based, I guess it makes sense to call range-based programming functional in spirit (although not so much on a technical level, e.g. recursiveness). And you can do similar things with iterators, although the C++ stdlib does not provide much out-of-the-box. In the context of the linked article I think maybe he is assuming that you should have SIMD access to the values, so maybe there is an underlying assumption there that libraries for ranges/iterators don't support SIMD well in their current incarnations. Anyway, I think you can rely on RVO in C++ in 2017, maybe not in 2012. But the addition of constexpr to C++ has made some improvements to the C++ ecosystem where D used to be a little bit ahead. The improvements to C++ in C++14 and C++17 are relative small, but as far as I am concerned, those improvements has enabled a more functional style of programming for initialization (small scale functional programming). Ola.
Re: Required Reading: "How Non-Member Functions Improve Encapsulation"
I've noticed the benefits of writing non member functions in Python codebases. Say if you have a User model in a Django ORM, and you have a Thing model, and some operation on User and Thing. I've noticed that your code is almost always better if you write a non member function on User and Thing, instead of a member of User or Thing. Often a function belongs to neither type. Instead the logic cuts across those two types. The key disadvantage I notice is ending up with very large and unreadable classes which poorly categorise business logic, when you could have been categorising functions in modules based on different business needs.
Re: Note from a donor
On Wednesday, 25 October 2017 at 22:46:27 UTC, Adam Wilson wrote: On 10/25/17 11:23, H. S. Teoh wrote: On Wed, Oct 25, 2017 at 08:17:21AM -0600, Jonathan M Davis via Digitalmars-d wrote: [...] [...] Yeah. There have been timing attacks against otherwise-secure crypto algorithms that allow extraction of the decryption key. And other side-channel attacks along the lines of CRIME or BREACH. Even CPU instruction timing attacks have been discovered that can leak which path a branch in a crypto algorithm took, which in turn can reveal information about the decryption key. And voltage variations to deduce which bit(s) are 1's and which are 0's. Many of these remain theoretical attacks, but the point is that these weaknesses can come from things you wouldn't even know existed in your code. Crypto code must be subject to a LOT of scrutiny before it can be trusted. And not just cursory scrutiny like we do with the PR queue on github; we're talking about possibly instruction-by-instruction scrutiny of the kind that can discover vulnerabilities to timing or voltage. I would not be comfortable entrusting any important data to D crypto algorithms if they have not been thoroughly reviewed. T I am one-hundred-ten percent in agreement with Mr. Teoh here. Even .NET Framework and Core forward to the highly vetted system crypto API's (SChannel on Windows and OpenSSL on Linux/macOS). If you need RSA crypto in D, pull in OpenSSL. Period. Everything else is a good way to run afoul of a security audit, and potentially expose yourself. Phobos could forward to these system provided API's like .NET does and provide an idiomatic D interface, but Phobos itself should absolutely and 110% stay out of the crypto implementation business. I think you made a very good point, it was also mentioned by someone else in this thread. Phobos could provide a crypto interface with implementions for SChannel, mbedtls, openssl. On Windows SChannel would be used as default implementation and on the other operation systems either openssl or mbedtls. This would be very convenient and we would avoid opening the Pandora box. I will close my issue and create a new one with the request for a crypto interface in Phobos. Kind regards Andre
