Hej !
I wonder if there is a kind of meta like @:deprecatd but more somehing like @:warning, which will only write awarning at compilation like @:deprecated but @:deprecated means that it’s deprecatd, I only want a simple warning… I don’t know if it’s clear…
In other words, I think there would be better to rename @:deprecated meta into @:warning meta and people would use it to what they want (deprectated info or others)
You can make a macros for this, but I’m just curious what kind of warnings you want to display?
I know I can do macro but since this @:deprecated meta does just that, IMHO it could be used for that as a global thing.
In my case I just want remember me at compilation that I’m using a “dangerous” function and I have to do some changes in my server so this function fit well and gives me what I really expect…
This is a standard annotation. Analogs @:deprecatded are available in other languages. This not only gives you a warning, but also documents the code. Extension vshaxe rendered deprecated things with strikethrough (which is very convenient). I’m sure no one will change that.
First thing is that I’m also sure that no one will change that, I know a little all that 
But IMHO my suggestion isn’t so stupid because it could be something more global, you could use it as now and telling in the message that it’s deprecated, instead of @:deprectated( "Be careful, it will be remove blabla" ) you could have @:warning( "This field is deprecated, it will be removed" ) or something like that. And in the same time you would be able to throw other “warnings” if you want. It also would change -D no-deprecated-warnings into -D no-warnings.
And also when you speak about documentation, what is the difference having @:deprecated(...) and @:warning(...) that could also end in the documentation. I mean, when you read the code or the doc, you see that it’s a warning… Or maybe I haven’t well understood ?
The reason why I suggest something like that, knowing that I can do it with macro, is that using macro, even if you work with a kind of “hub”, it will always be slower that having it in compiler which yet has a “meta processor”.
The warning you want to see is addressed to the library developer. The user should not see messages that the developer has not completed some things. Why not remind yourself of something in more familiar ways, for example, with //TODO comments.
How do you know who I want to see the warning ?
Thanks for the talk, I’ll end for now with that 
You said it yourself 
Ok, but I said also that I personnaly know that I can make it using macros and if I’ve posted that it’s to know if it could be done in a global case, that means for others people with maybe other needs that mine
Anyway, this will break backward compatibility. A special render for deprecated things, which was added not so long ago, will also stop working in vshaxe. The only thing I would probably change is to somehow combine the meta @:deprecated and the Javadoc annotation @deprecated, since they carry the same information, but if we want to see both compiler warnings and Javadoc-style documentation, we have to duplicate these things.
In order to keep back compatibility is to add @:warning and not replace @:deprecated. I think adding that in the yet implemented compiler macro processor wouldn’t be so heavy especially that it could be add to the @:deprecated case. In fact it’s all about the case, all the rest is yet implemented and works as wanted. + adding -D no-warning also in this -D no-deprecated-warning case.
© 2018-2020 Haxe Foundation - Powered by Discourse
