Re: interfaces and contracts - new pattern
On Tuesday, 3 December 2019 at 02:57:13 UTC, Adam D. Ruppe wrote: On Monday, 2 December 2019 at 22:31:08 UTC, Ola Fosheim Grøstad wrote: Interesting, could be useful, but now you have to remember to add "in(false)". Yeah, it is kinda tempting to propose a language change, where an override method does this by default if nothing else is specified. I think it would probably usually be the right thing to do, and then you'd opt into extending it all the way by doing `in(true)` instead. Yes, I agree, if you forget to add a specification then it probably should have the same strictness as the superclass. That is what I would expect.
Re: interfaces and contracts - new pattern
On Monday, 2 December 2019 at 22:31:08 UTC, Ola Fosheim Grøstad wrote: Interesting, could be useful, but now you have to remember to add "in(false)". Yeah, it is kinda tempting to propose a language change, where an override method does this by default if nothing else is specified. I think it would probably usually be the right thing to do, and then you'd opt into extending it all the way by doing `in(true)` instead. I wonder if this could somehow be wrapped up in a clean way using meta-programming so you always get the "in(false)"? I don't think so, contracts are invisible to reflection right now (unless there's a trick I don't know). Maybe a language change is warranted though, I don't really know, especially since this thing is possible today.
Re: interfaces and contracts - new pattern
On Monday, 2 December 2019 at 20:30:49 UTC, Adam D. Ruppe wrote: Wrote about it in more details here: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_02.html i think this is a pretty cool little discovery, thanks too for the folks on irc for chatting it through. Interesting, could be useful, but now you have to remember to add "in(false)". I wonder if this could somehow be wrapped up in a clean way using meta-programming so you always get the "in(false)"?
interfaces and contracts - new pattern
In short use `in(false)` when you `override` a function to inherit the contract, unless you explicitly want to expand the input - which you shouldn't do when implementing an interface! Wrote about it in more details here: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_02.html i think this is a pretty cool little discovery, thanks too for the folks on irc for chatting it through. destroy if i missed anything lol
Re: LDC 1.19.0-beta2
On Sunday, 1 December 2019 at 19:11:53 UTC, Dennis wrote: I have Visual Studio installed. How do I know which import libraries are being used? Then you're most likely NOT using the MS toolchain, since it has to be explicitly enabled (see README.txt). - It can be verified by checking the DLL dependencies of generated binaries (e.g., dependency on ucrtbase.dll -> most likely NOT using MS toolchain) or linking with `-v` to check the linker cmdline (containing /LIBPATH:...\mingw -> NOT using MS toolchain). I only had some issues with the old OMF ones, so I don't tend to use that target. LDC doesn't and has never supported support OMF.
