On Monday, March 20, 2017 22:47:24 Adam D. Ruppe via Digitalmars-d-learn
wrote:
> The rules make sense alone, but together, they are just bizarre.
That's frequently where the language design pitfalls lie. Well-meaning
features that seem perfectly reasonable on their own (possibly even
unreasonabl
On Monday, 20 March 2017 at 21:04:30 UTC, Ali Çehreli wrote:
Agreed. Surprisingly, there are quite a number of issues that
request exactly that, mostly thanks to our old friend
bearophile. The following may be the reason for this WAT:
This is another case where I can kinda get it in isolation,
On 03/20/2017 09:31 AM, Adam D. Ruppe wrote:
On Monday, 20 March 2017 at 16:04:10 UTC, Kagamin wrote:
https://dpaste.dzfl.pl/eafa86c5426d
Unbelievable, we're both right, sort of.
So it is true that typeof(static[]) == dynamic.
But the language also allows implicit conversion in the other
dir
On Monday, 20 March 2017 at 16:04:10 UTC, Kagamin wrote:
https://dpaste.dzfl.pl/eafa86c5426d
Unbelievable, we're both right, sort of.
So it is true that typeof(static[]) == dynamic.
But the language also allows implicit conversion in the other
direction WTF. If you put a variable in betw
On Monday, 20 March 2017 at 15:46:10 UTC, Adam D. Ruppe wrote:
On Monday, 20 March 2017 at 15:38:26 UTC, Kagamin wrote:
This explicit slice won't work, because a slice of a fixed
size array results in a fixed size array.
No, it doesn't. int[4] a; typeof(a[] == int[])
You can try yourself in t
On Monday, 20 March 2017 at 15:38:26 UTC, Kagamin wrote:
This explicit slice won't work, because a slice of a fixed size
array results in a fixed size array.
No, it doesn't. int[4] a; typeof(a[] == int[])
You can try yourself in the compiler, it is easy to verify.
On Thursday, 16 March 2017 at 17:50:45 UTC, Adam D. Ruppe wrote:
string s = func()[]; // I'd allow it, at least the user wrote
`[]` meaning they realized it was stack data and presumably
knows what that means about the slice's lifetime
This explicit slice won't work, because a slice of a fixed
On Monday, 20 March 2017 at 04:03:20 UTC, Vladimir Panteleev
wrote:
https://issues.dlang.org/show_bug.cgi?id=9279
Has it not been fixed?
That's specific to the return statement. Like you can assign an
address of a local variable, but you can't return it.
On Thursday, 16 March 2017 at 16:13:33 UTC, Carl Sturtivant wrote:
What's going on here?
Looks like this bug:
https://issues.dlang.org/show_bug.cgi?id=9279
Has it not been fixed?
On Thursday, 16 March 2017 at 22:06:24 UTC, H. S. Teoh wrote:
On Thu, Mar 16, 2017 at 02:36:15PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote: [...]
Honestly, I think that it was a big mistake to have implicit
slicing of static arrays in the language at all.
That makes at least 3 of u
On Thu, Mar 16, 2017 at 06:51:45PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Thursday, 16 March 2017 at 18:07:09 UTC, Petar Kirov [ZombineDev] wrote:
> > Why don't you use -dip1000???
>
> Because it isn't the default. But even if it was, people would ask
> "why is this giving me an
On Thu, Mar 16, 2017 at 02:36:15PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
[...]
> Honestly, I think that it was a big mistake to have implicit slicing
> of static arrays in the language at all.
That makes at least 3 of us -- Adam, you, me. I'm sure there are more.
> Unfortunatel
On Thursday, March 16, 2017 20:42:21 Carl Sturtivant via Digitalmars-d-learn
wrote:
> Implicitly slicing rvalue arrays is too much like implicitly
> taking the address of an rvalue.
Well, that's just it. That's _exactly_ what's happening. It's just that it
ends up in a struct with a length member
On Thursday, 16 March 2017 at 18:51:45 UTC, Adam D. Ruppe wrote:
Phobos could have been written to avoid this problem too,
there's a few solutions that work, but right now, using the
standard library in a way people expect to work will be
silently disastrous.
Yes, and as an outsider I find th
On Thu, Mar 16, 2017 at 07:17:41PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Thursday, 16 March 2017 at 19:00:08 UTC, H. S. Teoh wrote:
> > Actually, https://issues.dlang.org/show_bug.cgi?id=12625 shows that
> > implicit slicing is still a problem:
>
> Oh yikes, I figured it would
On Thursday, 16 March 2017 at 19:00:08 UTC, H. S. Teoh wrote:
Actually, https://issues.dlang.org/show_bug.cgi?id=12625 shows
that implicit slicing is still a problem:
Oh yikes, I figured it would still be copied onto the local stack
even though it is an rvalue.
But you know, the fact that so
On Thu, Mar 16, 2017 at 06:41:40PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Thursday, 16 March 2017 at 18:10:43 UTC, H. S. Teoh wrote:
> > But in that case, wouldn't that mean implicit slicing isn't to blame
> > here? (Not that I'm arguing for implicit slicing -- I think it needs
>
On Thursday, 16 March 2017 at 18:07:09 UTC, Petar Kirov
[ZombineDev] wrote:
Why don't you use -dip1000???
Because it isn't the default. But even if it was, people would
ask "why is this giving me an error?" and the same explanation
would need to be given. Certainly, a compile error is better
On Thursday, 16 March 2017 at 18:10:43 UTC, H. S. Teoh wrote:
But in that case, wouldn't that mean implicit slicing isn't to
blame here? (Not that I'm arguing for implicit slicing -- I
think it needs to go, too, having been bitten by it before --
but this particular case wouldn't constitute as
On Thu, Mar 16, 2017 at 06:09:52PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Thursday, 16 March 2017 at 17:47:34 UTC, H. S. Teoh wrote:
> > Actually, the bug still exists even if you explicitly slice it:
> >
> > string x = func()[]; // still compiles, but shouldn't
>
> I don't
On Thursday, 16 March 2017 at 18:07:09 UTC, Petar Kirov
[ZombineDev] wrote:
On Thursday, 16 March 2017 at 17:51:41 UTC, Adam D. Ruppe wrote:
On Thursday, 16 March 2017 at 17:40:51 UTC, H. S. Teoh wrote:
Seems like the real cause of bug 17261 is implicit slicing.
Yes, sorry, it took me 10 mins
On Thursday, 16 March 2017 at 17:47:34 UTC, H. S. Teoh wrote:
Actually, the bug still exists even if you explicitly slice it:
string x = func()[]; // still compiles, but shouldn't
I don't call that a bug, once it is explicitly done it means the
programmer realized something is up and
On Thursday, 16 March 2017 at 17:20:10 UTC, Carl Sturtivant wrote:
OK, but if I try to do this,
char[2] u;
string s = u;
Yeah, that's because `u` is not necessarily unique like a
function return value:
char[2] u;
char[] mutable = u[];
string s = u[];
char before = s[0];
mutable[0] = 'n';
On Thursday, 16 March 2017 at 17:51:41 UTC, Adam D. Ruppe wrote:
On Thursday, 16 March 2017 at 17:40:51 UTC, H. S. Teoh wrote:
Seems like the real cause of bug 17261 is implicit slicing.
Yes, sorry, it took me 10 mins to type it up (I like to double
check the current behavior before posting)
On Thu, Mar 16, 2017 at 10:40:51AM -0700, H. S. Teoh via Digitalmars-d-learn
wrote:
[...]
> Is implicit slicing the culprit in the issue I just filed? (Bug 17261)
>
> In retrospect, perhaps implicit casting to immutable is OK if we don't
> allow implicit slicing:
>
> char[32] func() { char
On Thursday, 16 March 2017 at 17:40:51 UTC, H. S. Teoh wrote:
Seems like the real cause of bug 17261 is implicit slicing.
Yes, sorry, it took me 10 mins to type it up (I like to double
check the current behavior before posting) but I think we both
see it the same way now.
On Thursday, 16 March 2017 at 17:20:45 UTC, H. S. Teoh wrote:
I'm not convinced casting static array to immutable is OK.
Check this out:
You aren't casting static array to immutable there, it is being
implicitly sliced AND cased to immutable.
What I mean is:
char[32] s;
immutable(char)[32]
On Thu, Mar 16, 2017 at 05:06:39PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
[...]
> In isolation, implicit slicing can make sense but not with
> templates. In isolation, implicit immutable can make sense... but not
> with implicit slicing.
[...]
Is implicit slicing the culprit in t
On Thursday, 16 March 2017 at 17:20:45 UTC, H. S. Teoh wrote:
I'm not convinced casting static array to immutable is OK.
Check this out:
import std.stdio;
char[32] func() {
char[32] staticArr = "A123456789abcdefB123456789abcdef";
return staticArr; // OK,
On Thursday, 16 March 2017 at 17:18:30 UTC, Adam D. Ruppe wrote:
On Thursday, 16 March 2017 at 17:12:08 UTC, Carl Sturtivant
wrote:
I did that, and it made no difference. :(
wait a minute i just realized:
toHexString.d(11) in the error message
You named the file toHexString which means the *
On Thu, Mar 16, 2017 at 04:59:40PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Thursday, 16 March 2017 at 16:47:14 UTC, Carl Sturtivant wrote:
> > Silently cast to immutable without copying!??!!
> > This is so wrong.
>
> It is the implicit slicing that I really want removed from the
On Thursday, 16 March 2017 at 16:59:40 UTC, Adam D. Ruppe wrote:
Yet the documentation says there's a toHexString that returns
a string.
Yes, indeed, it returns a string if it is passed a dynamic
array.
Ah, that's the distinction, should have noticed.
Remember though, like I warned on my do
On Thursday, 16 March 2017 at 17:12:08 UTC, Carl Sturtivant wrote:
I did that, and it made no difference. :(
wait a minute i just realized:
toHexString.d(11) in the error message
You named the file toHexString which means the *module* will be
named toHexString by default...
So using the na
On Thursday, 16 March 2017 at 17:01:56 UTC, Adam D. Ruppe wrote:
On Thursday, 16 March 2017 at 16:56:11 UTC, Carl Sturtivant
wrote:
"toHexString.d(11): Error: function expected before (), not
module toHexString of type void"
Module???
huh idk.
use my search engine btw! http://dpldocs.info/t
On Thursday, 16 March 2017 at 16:46:43 UTC, H. S. Teoh wrote:
WAT?! Why does the language allow implicitly casting from
static array to string?! How is that even remotely correct?
Is there a bug filed for this?
Yeah, somewhere, bugzilla search sucks but I know it is in there
somewhere. We'
On Thursday, 16 March 2017 at 16:56:11 UTC, Carl Sturtivant wrote:
"toHexString.d(11): Error: function expected before (), not
module toHexString of type void"
Module???
huh idk.
use my search engine btw! http://dpldocs.info/toHexString
it is in `std.digest.digest` but that should be public
On Thursday, 16 March 2017 at 16:47:14 UTC, Carl Sturtivant wrote:
Silently cast to immutable without
copying!??!! This is so wrong.
It is the implicit slicing that I really want removed from the
language, it serves no real benefit and brings a lot of
accidental complexity. Casting the stati
On Thursday, 16 March 2017 at 16:21:08 UTC, Adam D. Ruppe wrote:
If I replace md5Of(arg).toHexString() with
toHexString(md5Of(arg))
That works for me though... maybe it is just a version mismatch
or something, since toHexString is in a different module than
md5of.
I have this problem on
On Thu, Mar 16, 2017 at 04:21:08PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Thursday, 16 March 2017 at 16:13:33 UTC, Carl Sturtivant wrote:
> > string ans = md5Of(arg).toHexString();
>
> That is a major D design flaw biting you the same way it has bitten so
> many others.
>
>
On Thursday, 16 March 2017 at 16:21:08 UTC, Adam D. Ruppe wrote:
On Thursday, 16 March 2017 at 16:13:33 UTC, Carl Sturtivant
wrote:
string ans = md5Of(arg).toHexString();
That is a major D design flaw biting you the same way it has
bitten so many others.
See the red box in my documentat
On Thursday, 16 March 2017 at 16:13:33 UTC, Carl Sturtivant wrote:
string ans = md5Of(arg).toHexString();
That is a major D design flaw biting you the same way it has
bitten so many others.
See the red box in my documentation fork:
http://dpldocs.info/experimental-docs/std.digest.digest
What's going on here?
```
import std.digest.md, std.stdio;
void main() {
string ans = hex("qwertyuiop");
writeln(ans);
}
string hex(string arg) {
string ans = md5Of(arg).toHexString();
writeln(ans);
return ans;
}
```
This compiles, and when run writes out corrupt nonsense fro
42 matches
Mail list logo
